ドメイン駆動設計（DDD: Domain-Driven Design）は、Eric Evans が著書 Domain-Driven Design: Tackling Complexity in the Heart of Software（2003、邦訳『エリック・エヴァンスのドメイン駆動設計』）で提唱したソフトウェア設計の考え方。
ソフトウェアが対象とする問題領域（ドメイン）についての知識をモデルとして整理し、そのモデルを中心に据えて設計・実装を進めることで、複雑なビジネスロジックに立ち向かうことを目的とする。
Domain-Driven Design is an approach to software development that centers the development on programming a domain model that has a rich understanding of the processes and rules of a domain.
要点：
ドメインエキスパート（業務に詳しい人）と開発者が協働し、共通の言葉（ユビキタス言語）でモデルを作る
モデルとコードを一致させる（モデル駆動設計）
大きく「戦略的設計」（モデルの分割・チーム間の関係）と「戦術的設計」（実装パターン）に分かれる
アーキテクチャ¶
DDDそのものは特定のアーキテクチャを強制しないが、ドメイン層をUIやデータベースなどの技術的関心事から隔離することが前提となる。
レイヤードアーキテクチャ¶
Evans本で紹介されている構成。上の層は下の層に依存してよいが、逆は不可。
| 層 | 責務 |
|---|---|
| プレゼンテーション層（UI） | ユーザーへの情報表示・入力の解釈 |
| アプリケーション層 | ユースケースの調整役。ビジネスルールは持たない（薄く保つ） |
| ドメイン層 | ビジネスの概念・ルール・状態。DDDの中心 |
| インフラストラクチャ層 | 永続化・メッセージングなどの技術的機能 |
派生アーキテクチャ¶
「ドメインを中心に置き、依存を外側から内側へ向ける」という同じ思想の変種として、以下がよくDDDと組み合わせられる。
オニオンアーキテクチャ（Jeffrey Palermo）
ヘキサゴナルアーキテクチャ／ポート＆アダプター（Alistair Cockburn）
クリーンアーキテクチャ（Robert C. Martin）
適用の注意点¶
軽量DDD（DDD-Lite）への批判：エンティティやリポジトリなどの戦術的パターンだけを取り入れ、ユビキタス言語や境界づけられたコンテキストといった戦略的設計を欠いた状態は「軽量DDD」と呼ばれ、DDDの本質（ドメインの理解とモデリング）が抜け落ちているとして批判される
コストに見合うか：ドメインが単純なCRUD中心のアプリケーションでは、DDDのモデリングコストが利益を上回らないことが多い。複雑なビジネスルールを持つコアドメインにこそ適用する価値がある
DDDは特定のアーキテクチャやフレームワークではなく、「ドメインの理解を中心に置く」という考え方。パターンの適用自体が目的化しないよう注意する
Serviceクラス¶
参考¶
Eric Evans (2003) Domain-Driven Design: Tackling Complexity in the Heart of Software（邦訳『エリック・エヴァンスのドメイン駆動設計』翔泳社）
Vaughn Vernon (2013) Implementing Domain-Driven Design（邦訳『実践ドメイン駆動設計』翔泳社）
成瀬允宣 (2020)『ドメイン駆動設計入門 ボトムアップでわかる！ドメイン駆動設計の基本』翔泳社
Domain-Driven Design Reference | Eric Evans（Evans本人によるパターンの要約。無料公開）