ドメイン駆動設計（DDD）とは？基本概念
ドメイン駆動設計（Domain-Driven Design、DDD）は、エリック・エヴァンスが2003年に提唱したソフトウェア設計手法です。その核心は「ビジネスの課題（ドメイン）を中心にソフトウェアを設計する」という考え方にあります。
従来のシステム開発では技術的な都合がシステム設計を主導しがちでしたが、DDDでは業務の専門家（ドメインエキスパート）と開発者が緊密に協力し、ビジネスの言葉をコードに忠実に反映させることを最優先とします。複雑なビジネスルールを持つエンタープライズシステム・ECサイト・SaaSプロダクトなどで特に効果を発揮します。
DDDの基本概念・用語
ユビキタス言語（Ubiquitous Language）
開発者とドメインエキスパートが共有する共通の言語体系です。「注文」「請求」「顧客」などのビジネス用語を、会話・ドキュメント・コードで一貫して使用します。ユビキタス言語の確立により、認識ズレによるバグや仕様の解釈違いを防ぎます。
境界付きコンテキスト（Bounded Context）
ユビキタス言語が一貫して適用される境界です。大きなシステムを意味のある単位（コンテキスト）に分割し、各コンテキストで独自のドメインモデルを持ちます。例えば「注文管理」と「在庫管理」はそれぞれ異なるコンテキストを持ち、「商品」という概念も各コンテキストで異なる属性・ルールを持つことがあります。
ドメインモデル
ビジネスの概念・ルール・プロセスをオブジェクトとして表現したモデルです。ドメインモデルはコードとして実装され、ビジネスの変化に追従して継続的に進化します。
DDDの戦術的パターン
エンティティ（Entity）
一意のIDで識別されるオブジェクトです。同じ属性値を持っていても、IDが異なれば別のオブジェクトとして扱います。例えば「顧客A（ID:001）」と「顧客B（ID:002）」は同姓同名であっても別エンティティです。エンティティは状態が変化してもIDで追跡し続けることができます。
値オブジェクト（Value Object）
IDを持たず、属性値によって等価性が判断されるオブジェクトです。「住所」「金額」「座標」などがその例です。値オブジェクトは不変（イミュータブル）に設計することが推奨されます。同じ住所であれば、どのインスタンスも等価として扱います。
集約（Aggregate）
関連するエンティティと値オブジェクトをまとめたクラスターです。集約は1つのルートエンティティ（集約ルート）を持ち、外部からのアクセスは必ず集約ルートを通じて行います。これによりデータの整合性をトランザクション境界として保証します。
リポジトリ（Repository）
集約の永続化と取得を担当するインターフェースです。データベースの具体的な実装詳細を隠蔽し、ドメインモデルがインフラ技術に依存しないようにします。
ドメインサービス（Domain Service）
エンティティや値オブジェクトに自然に属さないドメインロジックを担当するサービスです。「2つの口座間の振替処理」のように、複数の集約にまたがる操作を表現するのに適しています。
ドメインイベント（Domain Event）
ドメイン内で発生した重要な事象を表すオブジェクトです。「注文が確定した」「在庫が不足した」などのイベントをドメインオブジェクトとして明示的に表現することで、イベント駆動アーキテクチャとの親和性が高まります。
DDDの戦略的パターン
コンテキストマッピング
複数の境界付きコンテキスト間の関係を図で表現する手法です。上流・下流関係・共有カーネル・腐敗防止層などのパターンを用いてコンテキスト間の連携方法を設計します。
腐敗防止層（Anti-Corruption Layer）
外部システムや異なるコンテキストからのデータ・概念が自分のドメインモデルを「汚染」しないよう保護する層です。外部システムとのインターフェース部分に変換ロジックを置き、自分のコンテキストのモデルの純粋性を保ちます。
DDDのメリット・デメリット
メリット
- ビジネスの変化に追従しやすい柔軟な設計を実現
- 開発者とビジネス担当者の認識ズレを減らせる
- 複雑なビジネスロジックをコードで正確に表現できる
- マイクロサービスアーキテクチャとの親和性が高い
デメリット
- 習得コストが高い（エンティティ・値オブジェクト・集約の設計判断が難しい）
- シンプルなCRUDアプリにはオーバーエンジニアリングになりやすい
- ドメインエキスパートとの密な協力が必要
AIシステム開発へのDDDの適用
AI・機械学習システムの開発にもDDDは応用できます。「モデル」「実験」「特徴量」「予測結果」などをドメインオブジェクトとして設計することで、AIシステムのビジネスロジックを明確に表現できます。renue社では、AIコンサルティングプロジェクトにおいてDDDの考え方を活用し、ビジネス要件をAIシステムに正確に反映させる設計を実践しています。
AIシステムのドメイン設計はrenueへ
renueはDDDとクリーンアーキテクチャを活用したAIシステム設計・実装を支援しています。ビジネス要件をコードに正確に反映させた高品質なAIシステムを構築します。
無料相談はこちらよくある質問（FAQ）
Q. DDDはどんなプロジェクトに向いていますか？
複雑なビジネスルールを持つエンタープライズシステム・ECサイト・金融系システムなど、ビジネスロジックが複雑で長期間メンテナンスが必要なプロジェクトに特に向いています。シンプルなCRUDアプリには不向きです。
Q. エンティティと値オブジェクトをどう区別すればよいですか？
「同一性（IDで区別する必要があるか）」が判断基準です。同じ属性値でも異なるものとして追跡する必要がある場合はエンティティ、属性値が同じなら同じものとして扱える場合は値オブジェクトです。
Q. DDDとマイクロサービスの関係は？
DDDの境界付きコンテキストは、マイクロサービスの分割単位の指針として活用できます。各マイクロサービスが1つの境界付きコンテキストに対応するという設計が一般的なパターンです。
Q. ユビキタス言語はどのように作成しますか？
開発者とドメインエキスパートが繰り返しの対話を通じて共同作成します。業務の専門用語を洗い出し、各用語の定義・コンテキストを合意し、ドキュメント・コードに一貫して使用します。
Q. DDDとクリーンアーキテクチャは一緒に使えますか？
はい、非常に相性が良いです。DDDで設計したドメインモデル（エンティティ・値オブジェクト・集約）をクリーンアーキテクチャの最内部の層に配置するパターンが広く採用されています。