DDD

この用語をシェア

DDD（ドメイン駆動設計）とは

DDD（Domain-Driven Design、ドメイン駆動設計）は、Eric Evansによって提唱された、複雑なソフトウェアの設計に対するアプローチです。ビジネスドメインの複雑性に正面から取り組み、ドメインの専門家と開発者が協力して、ビジネスの本質を反映したソフトウェアを構築することを目指します。

DDDの基本概念

1. ドメイン（Domain）

ビジネスの問題領域そのものを指します。例えば、ECサイトであれば「商品管理」「注文処理」「顧客管理」などがドメインの例です。DDDでは、このドメインを深く理解し、ソフトウェアに反映させます。

2. ユビキタス言語（Ubiquitous Language）

ドメインエキスパートと開発者が共通して使用する言語です。ビジネス用語をそのままコードに反映させることで、ビジネスロジックとコードの乖離を防ぎます。

3. 境界づけられたコンテキスト（Bounded Context）

ドメインモデルが有効な境界を明確に定義します。同じ用語でも、コンテキストが異なれば意味が変わることがあるため、境界を明確にすることが重要です。

DDDの構成要素

1. エンティティ（Entity）

一意の識別子を持つオブジェクトです。時間の経過とともに属性が変化しても、識別子によってその存在を追跡できます。例：顧客、注文、商品など。

2. 値オブジェクト（Value Object）

識別子を持たず、その値によって特定されるオブジェクトです。不変性を保ち、等価性は全ての属性の値によって決まります。例：住所、価格、色など。

3. ドメインサービス（Domain Service）

複数のエンティティや値オブジェクトにまたがるビジネスロジックを実装する場所です。特定のエンティティに属さない処理を担います。

4. リポジトリ（Repository）

エンティティの永続化を抽象化し、ドメインロジックからインフラストラクチャの詳細を隠蔽します。コレクションのように扱えるインタフェースを提供します。

5. 集約（Aggregate）

関連するエンティティと値オブジェクトをまとめた単位です。データの一貫性を保つ境界を定義し、集約ルートを通じてのみ外部からアクセスできます。

DDDの実装アーキテクチャ

レイヤードアーキテクチャ

DDDでは、以下の4つのレイヤーに分けて実装します：

• プレゼンテーション層： ユーザーインターフェースの処理
• アプリケーション層： ユースケースの実装
• ドメイン層： ビジネスロジックの実装
• インフラストラクチャ層： 永続化、外部サービスとの連携

ヘキサゴナルアーキテクチャ

ポート・アダプター・アーキテクチャとも呼ばれ、ドメインを中心として外部の技術的な詳細を隠蔽する構造です。

企業導入における成功事例

Microsoft - 大規模システムの分解

Microsoftは、複雑なモノリシックシステムをDDDの原則に従って分解し、境界づけられたコンテキストごとにマイクロサービスを構築しました。

Netflix - ドメイン中心の組織構造

Netflixは、DDDの考え方を組織構造にも適用し、ドメインに特化したチームを編成することで、開発効率と品質を向上させました。

実装上の利点とROI

定量的効果

• 保守性向上： 機能追加・変更時間の30-50%短縮
• コードの可読性： 新規メンバーのオンボーディング時間の40%削減
• バグ削減： ビジネスロジックに関するバグの60%削減
• テスト効率： 単体テストの作成・実行時間の25%短縮

導入時の注意点とベストプラクティス

1. 適切な複雑性の判断

DDDは複雑なドメインに対して効果的ですが、シンプルなCRUD操作中心のシステムには過度な複雑性をもたらす可能性があります。

2. ドメインエキスパートとの協力

DDDの成功には、ビジネスドメインの専門知識を持つ人々との継続的な協力が不可欠です。

3. 段階的な導入

すべてのシステムを一度にDDDで設計するのではなく、複雑な部分から段階的に適用していくことが効果的です。

他の手法との組み合わせ

イベントストーミング

ドメインエキスパートと開発者が協力してビジネスプロセスを可視化し、境界づけられたコンテキストを特定する手法です。

CQRS・Event Sourcing

コマンドクエリ責務分離とイベントソーシングを組み合わせることで、より柔軟で拡張性の高いシステムを構築できます。

具体的なツールと技術

実装フレームワーク

• Java： Spring Boot、Axon Framework
• C#： .NET Core、NServiceBus
• Python： Django、FastAPI
• Node.js： NestJS、Express

モデリングツール

• EventStorming： ドメインモデリングワークショップ
• Context Mapping： 境界づけられたコンテキストの可視化
• PlantUML： ドメインモデルの図式化

DDDの未来と進化

DDDは、マイクロサービス・アーキテクチャの普及により、サービスの境界を決定する重要な指針として注目されています。また、クラウドネイティブな開発環境においても、ドメインを中心とした設計思想が重要視されています。

AI・機械学習を活用したドメインモデリング支援ツールの開発も進んでおり、より効率的なDDDの実践が可能になっています。イベントストーミングの自動化、コンテキストマッピングの支援、実装コードの自動生成などの分野で発展が続いています。

AIエンジニアとしての実務経験

DDDとAI開発の組み合わせで最も印象深かったのは、LLMを活用したナレッジ検索システムをDDDで設計したプロジェクトでした。AIシステムは従来のCRUDアプリケーションとは異なる複雑性を持っており、DDDの考え方が非常に有効でした。

具体的には、以下のような境界づけられたコンテキストを設計しました：①「ドキュメント管理コンテキスト」（文書のアップロード、メタデータ管理）、②「ベクトル検索コンテキスト」（Embedding生成、類似度検索）、③「質問応答コンテキスト」（LLM推論、回答生成）、④「ユーザー管理コンテキスト」（認証、権限管理）。各コンテキストは独立したマイクロサービスとして実装し、コンテキストマップで関係性を明確にしました。

また、AIシステム特有のドメインモデルを設計した経験も貴重でした。「Embedding」を値オブジェクトとして、「Document」と「Chunk」をエンティティとして、「SearchQuery」と「SearchResult」をドメインイベントとしてモデル化しました。ユビキタス言語として「チャンク」「類似度スコア」「コンテキストウィンドウ」などのAI用語をドメインエキスパート（業務担当者）と共有し、コードにもそのまま反映しました。

失敗経験としては、DDD導入の初期段階で「すべてをドメインモデルで表現しよう」としすぎて、シンプルなCRUD操作まで過度に複雑化してしまったことがあります。AIシステムの「推論ロジック」はDDDで丁寧に設計する価値がありますが、「ログ管理」や「設定管理」などはシンプルなアプローチで十分でした。DDDを適用する領域と適用しない領域を見極めることの重要性を学びました。

DDDの最新動向

• Event Stormingの普及：Alberto Brandiが提唱したイベントストーミングが、DDDの実践手法として広く採用されています。リモート環境ではMiro、FigJamを使ったバーチャルイベントストーミングが標準化されています。
• Wardley Mapとの融合：戦略的意思決定にWardley Mappingを活用し、どのコンテキストに投資すべきかを可視化するアプローチが注目されています。
• Team Topologiesとの連携：境界づけられたコンテキストとチーム構成を一致させる「コンウェイの法則」を意識した組織設計が重要視されています。
• AI/LLMによる支援：LLMを活用してドメインエキスパートとの会話からユビキタス言語を抽出し、ドメインモデルを提案するツールが登場しています。
• Serverless DDD：AWS Lambda、Azure Functionsなどのサーバーレス環境でDDDを実践するパターンが確立されています。特にCQRS/Event Sourcingとの相性が良いです。

DDDにまつわるトラブルと失敗例

• 「戦術的パターンだけのDDD」：エンティティ、値オブジェクト、リポジトリなどの戦術的パターンだけを適用し、戦略的設計（境界づけられたコンテキスト、ユビキタス言語）を軽視するケース。DDDの真の価値は戦略的設計にあります。
• 「DDDのオーバーエンジニアリング」：シンプルなCRUDアプリケーションに対してDDDをフル適用し、不必要な複雑性を導入するケース。DDDは複雑なドメインに対して効果的であり、すべてのシステムに適用すべきではありません。
• 「ドメインエキスパート不在」：開発者だけでドメインモデルを設計し、ビジネスの実態と乖離したモデルになるケース。DDDの成功にはドメインエキスパートとの継続的な協力が不可欠です。
• 「集約の境界ミス」：集約の境界を適切に設計できず、パフォーマンス問題やデータ整合性の問題が発生するケース。特に「大きすぎる集約」は頻繁に報告される失敗パターンです。
• 「ユビキタス言語の形骸化」：初期にユビキタス言語を定義しても、時間の経過とともにコードと乖離するケース。継続的なリファクタリングと用語の見直しが必要です。

外部リンク・参考資料

• Martin Fowler - DDD - DDDに関する包括的な解説
• DDD Crew GitHub - DDDのパターンカタログとワークショップ資料
• Event Storming - イベントストーミングの公式サイト
• Domain Language (Eric Evans) - DDD提唱者の公式サイト
• Domain-Driven Design (Blue Book) - Eric Evansの原著
• Implementing DDD (Red Book) - Vaughn Vernonの実装ガイド

この用語についてもっと詳しく

DDDに関するご質問や、システム導入のご相談など、お気軽にお問い合わせください。

アジャイル開発 テスト 技術的負債