第10章: DDDの未来 — AI時代の設計とチームトポロジー

DDDとLLM — Eric Evansの提言

2024年3月、Explore DDDカンファレンスでEric Evans自身がDDD実践者に向けて重要な提言を行いました。 「LLMについて今すぐ学び、実験を始め、結果をコミュニティに共有してほしい」というメッセージです。

Evansの主張の核心は、汎用LLM（ChatGPT等）に頼るのではなく、 特定の境界づけられたコンテキストのユビキタス言語でファインチューニングしたモデルの方がはるかに有用だということです。 これはDDDの「コンテキストごとにモデルを分離する」という原則と完全に一致しています。

訓練済みLLMをBounded Contextとして扱う

Evansは、複雑なシステムの未来像として3つの要素が共存するモデルを提示しました。

graph TB
  subgraph system[複雑なシステムの3要素]
    A[構造化されたドメインモデル\n従来のDDDコード] 
    B[人間が扱う部分\nUI・意思決定]
    C[LLMが支援する部分\nドメイン特化モデル]
  end
  A <-->|ユビキタス言語| B
  A <-->|API・イベント| C
  B <-->|対話| C

  style A fill:#8b5cf6,stroke:#6d28d9,color:#fff
  style B fill:#3b82f6,stroke:#1d4ed8,color:#fff
  style C fill:#f97316,stroke:#ea580c,color:#fff

またEvansは、ゲームデザイナーReed Berkowitzとの実験から、 プロンプトを小さなチャンクに分割すると一貫性が向上することを発見しました。 これはDDDの「複雑な問題を小さく分解する」という根本原則と一致しており、 DDDの考え方がAI時代にも有効であることを示唆しています。

AIを活用したドメインモデリング

実際に、生成AIをドメインモデリングに活用するツールやアプローチが登場しています。

DDDとTeam Topologies — 組織設計との統合

2024-2025年のDDDコミュニティで最も注目されているトピックの1つが、 DDDとTeam Topologiesの統合です。 Susanne Kaiser著「Architecture for Flow」（Addison-Wesley, 2025）は、 3つのフレームワークを統合する画期的なアプローチを提示しました。

graph LR
  subgraph wardley[Wardley Mapping]
    W[ビジネス戦略\nコンポーネントの進化段階\nユーザーニーズ]
  end
  subgraph ddd[DDD]
    D[ソフトウェア設計\nBounded Context\nサブドメイン分類]
  end
  subgraph tt[Team Topologies]
    T[チーム編成\nストリームアラインド\nプラットフォーム]
  end
  W -->|何が重要かを特定| D
  D -->|どう分割するかを決定| T
  T -->|チームの認知負荷を管理| W

  style wardley fill:#f97316,stroke:#ea580c,color:#fff
  style ddd fill:#8b5cf6,stroke:#6d28d9,color:#fff
  style tt fill:#3b82f6,stroke:#1d4ed8,color:#fff

Architecture for Flowの3ステップ

1. Wardley Mapping（ビジネス戦略）: 組織のランドスケープを可視化し、ユーザーニーズとコンポーネントの進化段階をマッピングする
2. DDD（ソフトウェア設計）: モノリシックシステムを境界づけられたコンテキストに分解し、サブドメインを「コア」「サポーティング」「ジェネリック」に分類する
3. Team Topologies（チーム編成）: ストリームアラインド、プラットフォーム、イネーブリングチームを設定し、認知負荷を管理する

DDDのコンテキストマップパターンとTeam Topologiesのインタラクションモードには自然な対応関係があります。 たとえば、Customer-SupplierパターンはTeam Topologiesの「X-as-a-Service」インタラクションに対応し、 Partnershipパターンは「Collaboration」インタラクションに対応します。

プラットフォームエンジニアリングとDDD

Gartnerは2026年までに大規模ソフトウェアエンジニアリング組織の80%がプラットフォームエンジニアリングチームを設置すると予測しています。 DDDのジェネリックサブドメインの概念は、プラットフォームチームが提供すべき共通基盤の特定に直接活用できます。

Adidasの事例では、Team Topologiesの原則とプラットフォームエンジニアリングを組み合わせたデジタルトランスフォーメーションが成功しています。 DDDのBounded Contextがチーム境界を定義し、プラットフォームチームがジェネリックサブドメインを「内部プロダクト」として提供するモデルです。

最新アーキテクチャトレンド

モジュラーモノリスの台頭

2024-2025年にかけて、「モノリスファースト」「モジュラーモノリス」が顕著なトレンドとなっています。 マイクロサービスが過度な複雑性やコストを招くケースが認識され、 DDDのBounded Contextをモジュール境界として活用するモジュラーモノリスが再評価されています。

Vertical Slice Architecture + DDD

Jimmy Bogardが提唱するVertical Slice Architectureは、DDDと補完的に組み合わせることができます。 モジュラーモノリスがマクロレベルの分解（Bounded Context = モジュール境界）を担い、 Vertical Sliceがモジュール内部のミクロレベルの編成（機能単位でのコード組織化）を担います。

DDDの批判と限界

DDDを正しく実践するためには、その批判と限界を正直に認識することが不可欠です。

体系的文献レビューが示す9つの課題

2006年〜2023年の36本の査読済み研究を分析した体系的文献レビュー（SLR）では、 DDDの実践における9つの課題カテゴリが特定されました。

構造的な批判

DDDに対するより根本的な批判もあります。

• 適用範囲の限定: DDDは大規模・高複雑度のエンタープライズシステムに主に適用可能であり、シンプルなCRUDシステムには過剰投資になる
• 現代環境との乖離: フロントエンドがステートレスHTTP/Web中心、バックエンドがクラウドファーストのステートレス運用となった現代環境は、DDDの元来の前提（長寿命デスクトップアプリケーション）と異なる
• パターンの採用偏在: ユビキタス言語、Bounded Context、エンティティ/値オブジェクトは広く採用されるが、Core DomainやShared Kernelの実践報告は少ない
• 大規模失敗事例: ヘルスケアプラットフォームが1000万ドル以上を投資してDDD導入に失敗した事例も報告されている

これらの批判は、DDDを教条的に適用しないことの重要性を教えてくれます。 DDDはコアドメインに集中適用し、ジェネリックなサブドメインにはシンプルなアプローチを選ぶ、 というDDD自身の教えに忠実であることが成功の鍵です。

DDD学習ロードマップ

graph LR
  subgraph beginner[初級 0〜3ヶ月]
    B1[ユビキタス言語] --> B2[Bounded Context]
    B2 --> B3[Entity・Value Object・Aggregate]
  end
  subgraph intermediate[中級 3〜6ヶ月]
    M1[イベントストーミング] --> M2[コンテキストマップ]
    M2 --> M3[CQRS・Event Sourcing]
  end
  subgraph advanced[上級 6ヶ月〜1年]
    A1[Supple Design] --> A2[Team Topologies統合]
    A2 --> A3[DDD + AI/LLM]
  end
  beginner --> intermediate --> advanced

  style beginner fill:#14b8a6,stroke:#0d9488,color:#fff
  style intermediate fill:#3b82f6,stroke:#1d4ed8,color:#fff
  style advanced fill:#8b5cf6,stroke:#6d28d9,color:#fff

実践のための3つのアドバイス

1. 戦略的設計から始める: 多くの初学者が戦術的パターン（Entity, Repository等）から入りますが、DDDの真価は戦略的設計にあります。ユビキタス言語とBounded Contextの理解を最優先にしましょう
2. コアドメインにのみ適用する: すべてのサブドメインにDDDを適用する必要はありません。ビジネスの差別化要因であるコアドメインに集中し、それ以外はシンプルなアプローチを選びましょう
3. 完璧を求めず、反復的に改善する: DDDのモデルは最初から完璧である必要はありません。Eric Evansが強調するように、リファクタリングを通じて継続的にモデルを洗練させていくことが重要です

シリーズまとめ

全10章にわたるDDD Deep Diveシリーズでは、DDDの歴史と思想（第1章）から始まり、 戦略的設計（第2章）、戦術的設計（第3章）、しなやかな設計（第4章）とDDDの概念体系を学びました。 アーキテクチャパターン（第5章）、CQRS・イベントソーシング（第6章）で設計の選択肢を広げ、 イベントストーミング（第7章）とTypeScript実装（第8章）で実践力を身につけました。 そして適用判断（第9章）と未来の展望（本章）で、DDDを現実のプロジェクトに活かすための知恵を探りました。

DDDは20年以上の歴史を持つ設計手法ですが、マイクロサービス、モジュラーモノリス、AI/LLMと、 時代の変化に対応しながら進化を続けています。 DDDの本質は特定のパターンやフレームワークではなく、「ドメインの複雑さに正面から向き合い、 ドメインエキスパートと協働してモデルを育てる」という姿勢にあります。

この姿勢は、AI時代においてもなお（あるいはAI時代だからこそ）価値を持ち続けるでしょう。