ここまでの章で、DDDが「何を大切にしているか」はかなり明確になってきたはずです。

それでもなお、DDDは失敗します。 しかもその多くは、

  • 理解不足
  • 技術力不足

ではありません。

「DDDをやろうとしたから」失敗する

この章では、実務で本当によく見かけるDDDの失敗パターンを整理します。

失敗例を知ることは、 正解例を増やすよりも、ずっと設計判断の精度を上げてくれます。

失敗パターン1：最初から「正しいDDD」をやろうとする

最も多く、最も破壊力のある失敗です。

  • Entity / Value Object を最初から作り込む
  • Aggregate を先に決める
  • Repository をすべて interface に切る

設計としては「教科書的」に見えます。

しかし実務では、

  • ルールがまだ分からない
  • 境界もまだ曖昧
  • 将来の変更も見えていない

この状態で完成形を目指すと、

想定外の変更に耐えられない設計

が出来上がります。

DDDは「完成形から逆算する設計」ではありません。 変化し始めたところに追従する設計です。

失敗パターン2：用語を揃えずにコードだけDDDにする

DDDの中核にあるのは、コードではなく言葉です。

それにもかかわらず、

  • クラス名だけDDDっぽい
  • メソッド名がユースケースとズレている
  • チーム内で同じ概念を別の言葉で呼んでいる

こうした状態でDDDを導入すると、

見た目はDDD、中身はカオス

になります。

言葉が揃っていない設計は、

  • レビューで揉める
  • 仕様変更の議論が噛み合わない

という形で、確実に破綻します。

失敗パターン3：UseCaseを薄くしすぎる

「UseCaseは薄くあるべき」という言葉が、 誤って伝わると起きる失敗です。

  • UseCaseがRepositoryを呼ぶだけ
  • 判断はすべてモデルに押し込む

一見きれいですが、

  • 処理の流れが追えない
  • どこで何が起きているか分からない

状態になります。

UseCaseは、

やりたいことの物語を書く場所

です。

薄くする対象は「責務」であって、 存在感そのものではありません。

失敗パターン4：モデルにルールを閉じ込めすぎる

第8章で述べた内容の裏返しです。

  • 画面固有の判断
  • 一時的な仕様
  • 今回だけの例外

こうしたロジックまでモデルに入れると、

  • モデルが巨大化する
  • 変更が怖くなる

結果として、

「触れないモデル」

が生まれます。

モデルは、

  • 概念の整合性を守る場所

であって、

  • すべての判断を引き受ける場所

ではありません。

失敗パターン5：DDDを全体に一律適用する

これも非常によくある失敗です。

  • すべての画面
  • すべての機能
  • すべてのCRUD

にDDDを適用しようとする。

結果として、

  • 開発速度が落ちる
  • 学習コストが爆発する
  • チームが疲弊する

DDDは、

壊れたら困るところにだけ使う設計

です。

割り切りのないDDDは、 プロジェクトを壊します。

失敗パターン6：「DDDっぽさ」を評価軸にする

レビューで、こんな言葉が出始めたら危険信号です。

  • それDDDっぽくないよね
  • もっとドメイン寄りにすべきでは？

この評価軸は、

設計を宗教に変える

力を持っています。

DDDの評価軸は、ただ一つです。

  • 変更が入ったときに助けてくれるか

それ以外の指標は、 すべて二次的です。

この章のまとめ

DDDの失敗は、

  • 技術が足りないから
  • 知識が足りないから

起きるのではありません。

多くの場合、

真面目にやりすぎた結果

として起きます。

DDDは、

  • 厳密である必要はありません
  • 完璧である必要もありません

ただ、

変化に備えるための考え方

であり続けること。

それを忘れなければ、 DDDは必ず実務の味方になります。

次の章では、 ここまでの理解を踏まえたうえで、 「ではDDDをどう学び、どう付き合っていくか」 という、より長期的な視点に進みます。