DDDはなぜ必要か

DDDが生まれた背景

ソフトウェアが失敗する原因の大半は、技術的な問題ではなく業務の理解不足にある。

• 仕様書通りに作ったのに、実際の業務で使われない
• ビジネスロジックがどこにあるかわからない（サービス？DB？フロント？）
• 新しい要件を追加するたびにバグが出る

これらは、コードが現実のビジネスを正確に反映できていないから起きる。

DDDが解決しようとすること

ソフトウェアの中心に「業務（ドメイン）」を置くこと。

従来の発想：
  要件定義 → DB設計 → API設計 → 実装

DDDの発想：
  ドメインを理解する → ドメインモデルを設計する → それをコードに写す

業務の言葉・ルール・概念がコードにそのまま現れていれば：

• 変更要件が来たとき「どこを直せばいいか」がわかる
• バグの原因を「業務的に何がおかしいか」で語れる
• 開発者と業務担当者が同じ言葉で話せる

「複雑さ」が大前提

Eric Evans は「DDDはすべてのプロジェクトに向かない」と最初に明言している。

DDDが有効なのは、業務ロジックが複雑な場合だけ。

状況	DDDの適合性
単純なCRUD（登録・表示・削除のみ）	過剰設計になる
業務ルールが複雑で変化し続ける	DDDの真価が出る
コアドメインで競争優位を作りたい	積極的に採用する

まとめ

業務の複雑さをソフトウェアで正確に表現し、変化に耐えられる設計を維持するための思想と実践集

「何を作るか」より先に「何のためのソフトウェアか」をモデルとして明確にし、それをコードに直結させることで、長期的に変更コストを下げるのがDDDの本質。

出典

ドメイン駆動設計（Eric Evans）序文 / 実践ドメイン駆動設計（Vaughn Vernon）第1章