この章では、DDDを「理論」や「美しさ」から一段引き離し、なぜDDDが現場で効くのかという実践的な理由を掘り下げます。

結論を先に言うと、DDDは「正しい設計」を目指すものではありません。DDDが本当に守ろうとしているのは、設計の耐久性です。

設計が壊れる瞬間は、コードが間違ったときではない

多くのエンジニアは、設計が壊れる原因を次のように考えがちです。

  • 初期設計が甘かった
  • スキルの低いメンバーが実装した
  • リファクタリングを怠った

しかし、実務で設計が壊れる瞬間を振り返ると、少し違う景色が見えてきます。

設計が壊れるのは、仕様が変わったときです。

  • 似ているけど微妙に違うルールが追加される
  • 例外ケースが後から増える
  • 「当初は想定していなかった」使われ方をされる

コードが間違っていたからではありません。 コードが、変化に耐えられなかっただけです。

DDDは、この「変化」を前提に設計を組み立てます。

「正しい設計」を目指すと、なぜ苦しくなるのか

設計の議論でよく聞く言葉があります。

  • この設計はDDDとして正しいのか？
  • この責務分割はCleanなのか？
  • 原則に反していないか？

こうした問いは一見まっとうですが、DDDの本質からは少しズレています。

なぜなら、DDDにおいて重要なのは

この設計が、将来の変更にどれだけ耐えられるか

だからです。

設計原則は「守るべきルール」ではありません。 設計が壊れにくくなる方向性を示すヒントに過ぎません。

DDDは、正解集を与えてくれません。 代わりに、「どこが壊れやすいか」を教えてくれます。

DDDが一貫して嫌うもの

ここまでの章を通して、DDDが何度も避けようとしているものがありました。

それは、

意味の混線

です。

  • ドメインの意味と技術の都合が混ざる
  • 複数のユースケースの意図が1つのクラスに混ざる
  • 今の仕様と将来の仕様が同じif文に混ざる

混ざった瞬間、そのコードは「今は動くが、未来に弱い」状態になります。

DDDは、

  • レイヤーを分け
  • 境界を引き
  • 言葉を揃え

意味が混ざらないよう、徹底的に抵抗します。

それは美学ではありません。 変更時に壊れないための実務的な戦略です。

設計の良し悪しは「変更点の数」で測れる

DDD的な設計かどうかを見分ける、非常にシンプルな指標があります。

仕様変更が入ったとき、直す場所はいくつあるか

  • 1か所で済むなら、良い設計
  • あちこちに影響が飛ぶなら、壊れやすい設計

DDDは、この「影響範囲」を小さくするための道具箱です。

  • Entityに閉じた変更
  • UseCaseだけで完結する変更
  • Repositoryの差し替えで済む変更

こうした変更の仕方ができる設計は、結果として長生きします。

DDDは「慎重な楽観主義」である

DDDは、未来を完全に予測しようとはしません。

  • どう変わるかは分からない
  • でも、必ず変わる

この前提に立っています。

だからDDDは、

  • 早すぎる抽象化を避け
  • 今わかっている境界だけを引き
  • 変わり始めたところからモデルを育てる

という、慎重な姿勢を取ります。

楽観的すぎず、悲観的すぎない。 変化を信じて、備えすぎない。

このバランス感覚こそが、DDDの実践的な価値です。

この章のまとめ

この章で伝えたかったことは、次の一点に集約されます。

  • DDDは「正しさ」を証明するための理論ではない
  • DDDは「壊れにくい設計」を作るための考え方である

設計は、いつか必ず変更されます。 そのときに、

  • どこを直せばいいか分かる
  • なぜそうなっているか説明できる
  • 壊さずに手を入れられる

そういうコードを残すこと。

それがDDDが目指しているゴールです。