TL;DR
ドメインの専門家の知見をもとに、ソフトウェアをドメインに合わせてモデリングする設計手法。Eric Evans が 2003 年の著書『Domain-Driven Design: Tackling Complexity in the Heart of Software』で名付けた。
なぜ必要か
英語版 Wikipedia によると、DDD は次の 3 つを前提にしている。
- プロジェクトの主な関心を、中核となるドメインとそのロジックに置く
- 複雑な設計を、ドメインのモデルに基づいて行う
- 技術者とドメインエキスパートが協力し、繰り返しの中で概念モデルを洗練させる
仕組み
英語版 Wikipedia では、DDD の主な用語を次のように説明している。モデルは、ドメインの選ばれた側面を記述する抽象の体系である。ユビキタス言語は、ドメインエキスパート、ユーザ、開発者が共有する語彙で、ドメインモデルとシステムの要件の両方で使う。境界づけられたコンテキストは、あるドメインモデルが一貫して有効である範囲を定める。
モデルの構成要素には、属性ではなく同一性で区別されるエンティティや、属性を持つが概念上の同一性を持たない不変の値オブジェクトがある。
注意点
英語版 Wikipedia によると、モデルを純粋で有用に保つには、開発者が多くの分離とカプセル化を実装しなければならないという批判がある。Microsoft は、モデルが共通理解を作るのに明らかに役立つ、複雑なドメインに限って DDD を勧めている。