RailsでDDDは使えるのか？

~ 2026年02月05日 Omotesando.rb~ 登壇資料

Transcript

1. 1 RailsでDDDは使えるのか？ 
 ~ 2026年02月05日 Omotesando.rb~
2. 池上 寛登（ikechi） ⾃⼰紹介 SUZURI‧minne事業部 Web Engineer X: penpeenpen
3. • 国内最大級のハンドメイドマーケット • Railsで開発、リリースから 14年 • 技術的負債と向き合いながら日々開発中 3 minne について
4. Rails × DDDはあり？ 4
5. ソフトウェア開発の複雑さについて 5
6. コアドメインは複雑である。 • 競争優位性の源泉となる独自領域 • ビジネスロジックが最も複雑になる部分 （複雑でなければ差別化要因にならない） • minneのコアドメイン: ◦ 作品と購入者のマッチング ◦ ショップ運営 /ブランディング 6 本質的な複雑さ（Essential Complexity） 引用元：https://medium.com/nick-tune-tech-strategy-blog/core-domain-patterns-941f89446af5
7. 偶発的な複雑さ（Accidental Complexity） 7 Railsで複雑性が増す要因 • ActiveRecordでドメイン層とインフラ層が密結合 • 規模が大きくなるにつれて、モデルクラスに責務が集中しや すい（Fat Model） 引用元：https://www.taazaa.com/mvc-architecture-benefits-and-challenges/
8. 課題: 偶発的な複雑さをどう減らすか 8
9. 9 What is DDD • ドメイン駆動設計（Domain-Driven Design）の略称 • ドメインを中心に据えたソフトウェア設計手法 • ビジネスロジックを純粋に保つ DDDという選択肢 引用元：https://sixphere.com/en/blog/clean-architectures-and-ddd-a-practical-journey-part-1/
10. 私の考え: 部分的な採⽤はアリ。 10
11. クラウドワークス社 • 30万行超のRailsアプリケーション • Rails × DDDでリファクタリングを実施中 • 「新規開発では避けるが、レガシー改善には有効」 11 導⼊事例 出典： 変化に適応するソフトウェアアーキテクチャと組織構造への道程 ドメイン駆動設計の比類なきパワーでRailsレガシーコードなど大爆殺したるわあああ！！！
12. 12 • コアドメインのみにDDDを適用 • Generic、SupportingドメインはRails Way採用 コアドメインに集中する
13. • Step1: PORO、Form Objectなど小さく始める • Step2: 必要に応じてService、Repositoryを導入 13 段階的な導⼊
14. 14 Fat Modelの解消例
15. まとめ 15
16. • Rails × DDDは部分的にはアリ • Rails × DDD 導入のポイント ◦ Core Domainに集中 ◦ 段階的に導入 ◦ Rails Wayを壊さない 16 まとめ
17. ご静聴ありがとうございました！