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
120
Rubyで始める関数型ドメインモデリング
Shogo Takasaki
February 15, 2025
Tweet
Share
Other Decks in Programming
See All in Programming
定理証明プラットフォーム lapisla.net
abap34
1
1.8k
Boost Performance and Developer Productivity with Jakarta EE 11
ivargrimstad
0
390
第3回 Snowflake 中部ユーザ会- dbt × Snowflake ハンズオン
hoto17296
4
370
ML.NETで始める機械学習
ymd65536
0
130
Lottieアニメーションをカスタマイズしてみた
tahia910
0
130
Djangoにおける複数ユーザー種別認証の設計アプローチ@DjangoCongress JP 2025
delhi09
PRO
4
260
Domain-Driven Transformation
hschwentner
2
1.9k
Ruby on cygwin 2025-02
fd0
0
150
PHPのバージョンアップ時にも役立ったAST
matsuo_atsushi
0
130
Amazon Q Developer Proで効率化するAPI開発入門
seike460
PRO
0
120
AIの力でお手軽Chrome拡張機能作り
taiseiue
0
170
Serverless Rust: Your Low-Risk Entry Point to Rust in Production (and the benefits are huge)
lmammino
1
120
Featured
See All Featured
GitHub's CSS Performance
jonrohan
1030
460k
A Modern Web Designer's Workflow
chriscoyier
693
190k
The World Runs on Bad Software
bkeepers
PRO
67
11k
Fireside Chat
paigeccino
34
3.2k
BBQ
matthewcrist
87
9.5k
Scaling GitHub
holman
459
140k
Statistics for Hackers
jakevdp
797
220k
Faster Mobile Websites
deanohume
306
31k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
44
7k
Navigating Team Friction
lara
183
15k
How to Think Like a Performance Engineer
csswizardry
22
1.4k
Build The Right Thing And Hit Your Dates
maggiecrowley
34
2.5k
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クラスを返すことがある程度担保されているので、エラーパターンの把握が容 易。
まとめ • 部分的に関数型のアプローチを取り入れることで、設計や実装時に立ち返る指針 が出来た • それによりメンテナビリティ、テスタビリティが向上した