設計技法の向き不向き(DDD / TDD / Clean Architecture)
一言まとめ
設計技法は特定の問題を解く手段なので、「その問題がこのコードや組織にあるか」で採否を決める。解く問題が無い場面で使った失敗を、技法そのものの欠陥と取り違えない。
目次 4 sections
判断の軸
技法ごとに「解決したい問題」「効果」「相応しくない状況」を並べると、相応しくない状況は「解決したい問題が無い状況」とほぼ一致する。「DDD / TDD / Clean Architecture はアンチパターンだ」という批判の多くは、問題の無い場面に持ち込んだ結果の失敗である。ミノ駆動(@MinoDriven)がこの整理を表にまとめている。
| 技法 | 解決したい問題 | 効果 | 相応しくない状況 |
|---|---|---|---|
| ドメイン駆動設計 | 開発を続けるうちにプロダクトの価値がぼやけ、思いつきの開発になる。複雑なドメイン知識がコードで混乱し、機能性や変更容易性が落ちる | 競争優位を生む業務領域をコアドメインと定め、そこに開発リソースを優先して投じる戦略を立てやすくなる。コンテキストやドメインモデルでコアドメインの知識とロジックを整理できる | ドメイン知識が単純で CRUD で済む処理。ここに戦術的 DDD を適用するのは過剰設計 |
| テスト駆動開発 | 要件が不明瞭で不確実性が高いまま開発を進めなければならない | テストコードを先に書くことで要件を早期に具体化できる | 要件がすでに固まっている状況 |
| Clean Architecture | ドメインロジックが DB や Controller に依存しており、そちらの変更でロジックが壊れる | 技術層がドメイン層(Entity)に依存する構造にし、ドメイン層を変更に対して最も安定させる(安定依存の原則) | ドメインロジックが DB や Controller にあまり依存していないコード、または仕様がほぼ変わらないコード |
技法ごとの補足
- DDD は 2 層に分けて考える。 戦略的 DDD はコアドメインを決める活動で、戦術的 DDD はエンティティ・値オブジェクト・集約などの実装パターンである。上の表で過剰設計とされているのは、単純な CRUD に戦術的 DDD を当てる場合だけである。
- TDD の効能は要件の具体化だけではない。 回帰テストの安全網や、テストの書きにくさから設計の問題に気づける点もよく挙げられる。上の表は要件の具体化に絞った見方である。
- Clean Architecture の根拠は安定依存の原則である。 依存しているモジュールが多いほど、依存先の変更で壊れやすくなる。依存の向きを逆転させ、ドメイン層が他の層に依存しない形にする。
使い方
技法の採否を議論するときは、表の「解決したい問題」の列から始める。その問題が自分たちのコードや組織に見当たらなければ、技法の採用を見送ってよい。流行や好みで決めずに済む。
更新履歴
- 2026-10-12: 初版