TL;DR
- 問題を解決する前に、問題を正しく理解することが重要である。
- ドメインエキスパート、開発チーム、その他のステークホルダー、ソースコードがすべて同じモデルを共有し、ドメインエキスパートのメンタルモデルを翻訳せずにコードへ直接反映させる。これが DDD の最終目標である。
内容
共有モデルのメリット
ソフトウェアのモデルをビジネスのドメインと一致させると、次のメリットがある。
まず、市場に出すまでの時間を短くできる。エンジニアとコードがドメインエキスパートと同じモデルを共有しているので、適切な解決手段をすばやく開発できる。
次に、より多くのビジネス価値を生み出せる。問題に的確に沿った解決手段は、顧客満足度を高める。
さらに、無駄を減らせる。要件が明確になるので、誤解や手戻りに費やす時間が減る。どのコンポーネントの価値が高いかも明確になり、開発コストをそのコンポーネントに集中させるといった戦略を取りやすくなる。
最後に、保守と進化が容易になる。ドメインエキスパートのモデルとコードで表現したモデルが一致していれば、コードを変更しやすく、エラーも起きにくい。新しいメンバーも早く慣れることができる。
共有モデルを作るガイドライン
したがって、最初に共有モデルを作る必要がある。DDD のコミュニティは、そのためのガイドラインを開発している。
- データ構造よりも、ビジネスイベントやワークフローに焦点を当てる（ビジネスイベントを通じてドメインを理解する）
- ドメインをより小さいサブドメインに分割する（ドメインをサブドメインに分割する）
- 解決空間となる各サブドメインのモデルを作る（境界づけられたコンテキストを利用した解決手段の作成）
- 共通の言語（ユビキタス言語）を作り、プロジェクトに関わる全員で共有する（ユビキタス言語の創造）