Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Rubyで始める関数型ドメインモデリング
Search
Shogo Takasaki
February 15, 2025
Programming
0
110
Rubyで始める関数型ドメインモデリング
Shogo Takasaki
February 15, 2025
Tweet
Share
Other Decks in Programming
See All in Programming
DROBEの生成AI活用事例 with AWS
ippey
0
130
一休.com のログイン体験を支える技術 〜Web Components x Vue.js 活用事例と最適化について〜
atsumim
0
470
Grafana Loki によるサーバログのコスト削減
mot_techtalk
1
130
JavaScriptツール群「UnJS」を5分で一気に駆け巡る!
k1tikurisu
9
1.8k
Pythonでもちょっとリッチな見た目のアプリを設計してみる
ueponx
1
560
Ruby on cygwin 2025-02
fd0
0
140
Honoのおもしろいミドルウェアをみてみよう
yusukebe
1
210
CSS Linter による Baseline サポートの仕組み
ryo_manba
1
100
Formの複雑さに立ち向かう
bmthd
1
850
XStateを用いた堅牢なReact Components設計~複雑なClient Stateをシンプルに~ @React Tokyo ミートアップ #2
kfurusho
1
900
苦しいTiDBへの移行を乗り越えて快適な運用を目指す
leveragestech
0
590
SwiftUIで単方向アーキテクチャを導入して得られた成果
takuyaosawa
0
270
Featured
See All Featured
The Invisible Side of Design
smashingmag
299
50k
Bootstrapping a Software Product
garrettdimon
PRO
306
110k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
29
2.4k
A designer walks into a library…
pauljervisheath
205
24k
Unsuck your backbone
ammeep
669
57k
GraphQLの誤解/rethinking-graphql
sonatard
68
10k
Imperfection Machines: The Place of Print at Facebook
scottboms
267
13k
Optimizing for Happiness
mojombo
376
70k
Typedesign – Prime Four
hannesfritz
40
2.5k
Rebuilding a faster, lazier Slack
samanthasiow
80
8.8k
Embracing the Ebb and Flow
colly
84
4.6k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
251
21k
Transcript
Rubyで始める関数型ドメインモデリング 湘.なんか #2 @shogo_tksk / 2025/02/15
話しているひと • 高崎(@shogo_tksk) • 普段はRails/Reactを書いています • 一番好きなモールは湘南モールフィル🏝
今日話すこと • 関数型の思考を取り入れることで、より堅牢なコードをかける(かも?) • Rubyにおける実装例
モチベーション • 本書はF#で書かれているが、その考え方自 体は言語仕様に依らず普遍的。 • そのエッセンスをRuby / Railsで書かれた コードに落とし込むとしたらどうか? 引用:
https://amzn.asia/d/7Lh0iN4
関数型プログラミングのエッセンスとは?🤔
不変性(Immutable) • オブジェクトを直接変更せず、新しいオブジェクトを生成して操作を行う • 意図せず他のオブジェクトの状態を壊さない
純粋関数 • 引数が同じ場合、常に同じ値を返す(参照透過性) • 副作用を持たない(関数の場合は「値を返す」ことが主たる作用) 引数以外の状態に依存
None
Railsにおける典型的な副作用(I/O) 不純な世界(副作用)と計算を分離する I/O境界 I/O境界 👈ココを純粋に保ちたい
引用: https://zenn.dev/coconala/articles/2a885527bf2f32 ◦ dry-monadsというGemを使った例 ◦ 処理のステップ1つ1つを純粋関数にする ▪ 副作用を避けるため、例外を吐かない。大 域脱出もしない。 ▪
その代わりにResultクラス(Success / Failure)を返す ◦ そのステップを組み合わせることで、大きな処理 (ワークフロー)を作る 👈 ドメインロジックをそのまま書く
引用: https://gitlab.com/gitlab-org/gitlab/-/blob/d8b87be14c3c27eb7cfef1bc502d9cc4e5c8ff0f/app/services/service_response.rb • 独自でResultクラスを定義するパターン • Gem依存を避けたい、欲しいのは Resultク ラスのみで、多機能なのは too muchな場
合など • GitLabのコードでは独自に定義した Result を返すことでドメインロジック上の例外を表 現している
やってみて嬉しいポイント • 関数を純粋に保つことでテストが早い &書きやすい ◦ 副作用(I/O)とロジックを分離することで、純粋な計算として扱える。 ◦ 逆にテストが書きにくい場合は、責務の分割が適切じゃないかも?副作用を孕んでいない か?などを考えられるようになった。 ▪
よりよいコードを書くためにテストを書く • 各関数がResultクラスを返すことがある程度担保されているので、エラーパターンの把握が容 易。
まとめ • 部分的に関数型のアプローチを取り入れることで、設計や実装時に立ち返る指針 が出来た • それによりメンテナビリティ、テスタビリティが向上した