■ 1. 主張の骨子
- 成熟したWAF上でのDDD全面適用に反対:
- Ruby on RailsやNext.jsのような成熟した（メタ）フレームワーク・WAFを採用しながら、DDDやClean Architectureを全面適用する設計には基本的に反対する
- DDDやClean Architecture自体が悪いわけではない
- WAFを選んだ時点で受け入れたはずの設計思想を上書きしてしまうことに違和感がある
- 全面適用を唱える者への評価:
- メタフレームワークを使いながらDDDやクリーンアーキテクチャを唱える者は、基本的に政治がやりたい可能性が高い
- 上司の立場なら拒否し、同僚の立場なら同意しないことを基本マイルールとしている
- LaravelやRailsのような成熟したWAFに勝てることは滅多にない
■ 2. 反対する理由
- エコシステムの恩恵の自壊:
- WAFが持つ規約、拡張点、周辺エコシステムの恩恵を自分たちで破壊することになる
- Railsを構成する要素:
- Active RecordやMVC、Convention over Configurationまで含めてRailsである
- 過剰な包み込みの弊害:
- Repository、UseCase、独自Entityで何重にも包み始めると、Railsを使っているのにRailsを避けるためのコードが増えていく
- コスト増大とWAF採用の無意味化:
- プロジェクトの学習コストも保守コストも上がる
- WAFを採用した意味そのものが薄れる
■ 3. DDDが有効な場面
- 限定的に有効なケース:
- 複雑なドメインの境界を整理する場合
- 外部システムとの依存を切り離す場合
- WAFでは扱いにくい中核ロジックを独立させる場合
- 適用範囲の制約:
- その場合でもWAF全体を別の思想で包み直してはいけない
- 必要な場所だけに限定して利用すべきである
■ 4. 原則
- 郷に入れば郷に従え:
- WAFを採用した以上、まずWAFの流儀で作る
- 不足部分の扱い:
- どうしても足りない部分だけを、Open–Closed Principleに従い既存の仕組みを壊さず拡張する
- 脱RailsをRailsの中でやる必要はない