この章では、DDDを「思想」や「設計論」から一歩進めて、実務でどのように導入していくかを具体的なパターンとして整理します。

ここで扱うのは、理想形のDDDではありません。

  • 時間が足りない
  • メンバー全員がDDDを理解しているわけではない
  • 既存コードがすでに存在する

そうした前提の中で、それでもDDDの考え方がどう役に立つのかを見ていきます。

パターン1：UseCase境界を「変更の防波堤」にする

最も多くの現場で使われているDDDの形は、これです。

  • Domainは完全ではない
  • Entityも最小限
  • それでもUseCaseだけは守る

UseCaseを「やりたいこと単位」で切り、

  • 入力
  • 処理の流れ
  • Repository呼び出し

を閉じ込めます。

このとき重要なのは、UseCaseを肥大化させないことではありません。 重要なのは、

変更理由が1つに収まっているか

です。

多少長くても、

  • このUseCaseは「〇〇を登録する」
  • このUseCaseは「〇〇を取り消す」

と説明できるなら、それは実務的には十分にDDDです。

パターン2：モデルは「ルールが見え始めたところ」から導入する

実務でよくある失敗は、最初からモデル（EntityやValue Object）を作り込みすぎることです。

  • 状態遷移を全部入れる
  • 不変条件を先回りして書く
  • 将来使いそうなメソッドを生やす

結果として、

  • 使われないロジック
  • 想定外の変更
  • 消せない責務

がモデルに溜まっていきます。

実務では、

ルールが増え始めてからEntityを育てる

くらいが、ちょうど良いです。

最初は単なるdata classでも構いません。この段階で、それがEntityなのかValue Objectなのかを厳密に判断する必要はありません。 「これはモデルに閉じ込めた方が安全だ」と感じた瞬間が、導入タイミングです。

パターン3：Repositoryは「差し替えたい未来」が見えたら切る

理想論では、Repositoryは最初から切ります。

しかし実務では、

  • 当分DBは変わらない
  • APIも1種類しかない

というケースも多い。

その場合、無理にRepositoryを作る必要はありません。

ただし、次の兆候が見えたら要注意です。

  • テストでモックしたくなった
  • キャッシュを挟みたくなった
  • 取得方法の都合がUseCaseに漏れ始めた

この瞬間が、Repositoryを切るサインです。

DDDは「最初から全部やる」設計ではなく、 分離が必要になった瞬間を逃さない設計です。

パターン4：DTO変換が苦しくなったら、境界が間違っている

実務でDDDがつらくなるポイントの1つが、変換地獄です。

  • API DTO → Domain → UI Model
  • Entity → Domain → UseCase Input

変換コードが増えすぎると、

  • 何が本体なのか分からない
  • 修正が怖い

状態になります。

ここで疑うべきは、Mapperの書き方ではありません。

その境界、本当に必要か？

です。

DDDの境界は、

  • 技術が変わる
  • 責務が変わる
  • 意味が変わる

ところにだけ引くものです。

変換が苦しいのは、 意味がほとんど変わらない場所に境界を引いているサインかもしれません。

パターン5：「全部DDDにしない」という選択

現場で最も健全なDDD導入は、これです。

  • 複雑な部分だけDDD
  • CRUDは割り切る
  • 重要でない画面はシンプルに書く

DDDは、コストのかかる設計です。

  • 考える時間が必要
  • 言葉を揃える必要がある
  • 説明コストが発生する

だからこそ、

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

この割り切りが、実務では非常に強い。

DDDは「全体を支配する思想」ではなく、 要所を守るための武器です。

この章のまとめ

この章で紹介したパターンに、共通点があります。

  • 完璧を目指していない
  • 未来を言い当てようとしていない
  • 今つらくなり始めた場所にだけ手を入れている

これが、実務で生き残っているDDDの姿です。

DDDは、

  • 厳密で
  • 美しくて
  • 教科書的

である必要はありません。

変更が来たときに助けてくれるかどうか。 それだけが、実務における評価基準です。

次の章では、ここまでの実務パターンを踏まえ、 DDDを導入して失敗する典型パターンを整理します。

失敗例を知ることは、 成功例を知るよりも、ずっと役に立ちます。