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
88
Rubyで始める関数型ドメインモデリング
Shogo Takasaki
February 15, 2025
Tweet
Share
Other Decks in Programming
See All in Programming
なぜイベント駆動が必要なのか - CQRS/ESで解く複雑系システムの課題 -
j5ik2o
9
3.4k
Linux && Docker 研修/Linux && Docker training
forrep
24
4.5k
『品質』という言葉が嫌いな理由
korimu
0
160
社内フレームワークとその依存性解決 / in-house framework and its dependency management
vvakame
1
550
Java Webフレームワークの現状 / java web framework at burikaigi
kishida
9
2.2k
法律の脱レガシーに学ぶフロントエンド刷新
oguemon
5
730
Amazon Q Developer Proで効率化するAPI開発入門
seike460
PRO
0
110
第3回 Snowflake 中部ユーザ会- dbt × Snowflake ハンズオン
hoto17296
4
370
2024年のWebフロントエンドのふりかえりと2025年
sakito
1
240
データの整合性を保つ非同期処理アーキテクチャパターン / Async Architecture Patterns
mokuo
45
16k
ISUCON14公式反省会LT: 社内ISUCONの話
astj
PRO
0
190
SwiftUI Viewの責務分離
elmetal
PRO
1
220
Featured
See All Featured
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
656
59k
BBQ
matthewcrist
86
9.5k
Typedesign – Prime Four
hannesfritz
40
2.5k
Why Our Code Smells
bkeepers
PRO
336
57k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
29
2.2k
Adopting Sorbet at Scale
ufuk
74
9.2k
A Philosophy of Restraint
colly
203
16k
Fantastic passwords and where to find them - at NoRuKo
philnash
51
3k
VelocityConf: Rendering Performance Case Studies
addyosmani
328
24k
Rebuilding a faster, lazier Slack
samanthasiow
80
8.8k
Done Done
chrislema
182
16k
The Pragmatic Product Professional
lauravandoore
32
6.4k
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クラスを返すことがある程度担保されているので、エラーパターンの把握が容 易。
まとめ • 部分的に関数型のアプローチを取り入れることで、設計や実装時に立ち返る指針 が出来た • それによりメンテナビリティ、テスタビリティが向上した