Domain-Driven Design — ドメイン（業務）の言葉と構造をそのままコードに反映させる設計手法。Eric Evans が 2003 年の同名書籍で体系化した。
概要
DDD の核は 「コードとビジネス用語を同じ語彙で揃える」 こと。エンジニアが業務担当者と「ユビキタス言語」で会話し、その言葉どおりにクラス名・メソッド名・モジュール名を付ける。これによって仕様変更とコード変更が一対一で対応し、AI 駆動開発でも「何を作るか」を伝えるコストが大きく下がる。
戦略的設計と戦術的設計
DDD は 2 層に分かれる。
| 層 | 何を扱うか | 主要概念 |
|---|---|---|
| 戦略的設計 | システムをどう分割するか | Bounded Context / コンテキストマップ / ユビキタス言語 |
| 戦術的設計 | コンテキスト内でどう実装するか | エンティティ / 値オブジェクト / 集約 / リポジトリ / ドメインサービス / ドメインイベント |
戦術だけ真似して戦略を欠くと「DDD 風 CRUD」になりやすい。先に Bounded Context を切ることが効果の半分以上を占める。
主要な戦術パターン
| パターン | 役割 |
|---|---|
| エンティティ | 同一性（ID）で区別される、ライフサイクルを持つオブジェクト |
| 値オブジェクト | 値そのもので等価判定する、不変の小さな型（Money, Email など） |
| 集約 | 強い不変条件で結ばれたエンティティ群と、その境界 |
| リポジトリ | 集約を永続化から切り離して扱う抽象 |
| ドメインサービス | エンティティ・値オブジェクトに置きにくいドメインロジック |
| ドメインイベント | 「ドメインで起きた出来事」を一級のオブジェクトとして表現 |
なぜ AI 駆動開発で重要か
- ユビキタス言語が揃っていれば、AI への指示が短く正確になる（「
Order集約に割引を追加して」で意図が通る） - 集約・リポジトリの境界が明確だと、AI 生成コードの影響範囲がレビュー可能なサイズに収まる
- ドメインイベントが整理されていれば、新しい業務要求に対する追加点が予測しやすい
レガシーシステムとの関係
COBOL や RPG の業務プログラムは、DDD 的視点で見ると「業務ドメインの語彙が手続きに散在している」状態。モダナイゼーション時には、まずサービスプログラム（*SRVPGM）単位で集約候補を抽出するのが現実的な第一歩になる。
関連記事
- 開発手法ガイド：概要 — DDD を含む設計原則の積み上げ順序
- COBOL × DDD 設計パターン — レガシー言語に DDD を適用する具体例
- CTS-EC 共通商品マスタ — 共通マスタを Bounded Context 単位で整理した実例
関連用語
- ビジネスケイパビリティ — Bounded Context の境界線を業務側の言葉で引く前提
- 集約 — DDD の戦術的設計の中核
- リポジトリパターン — 集約を永続化詳細から切り離す
- ヘキサゴナルアーキテクチャ — DDD と相性の良いアーキテクチャ
- SOLID 原則 — DDD を支える設計原則
- RDD（責務駆動設計） — DDD の責務分析の系譜
- CQRS — DDD の発展形として書き込み・読み取りを分離
- イベントソーシング — ドメインイベントを永続化の真実とする手法