第9章: DDDの適用判断と導入戦略 — いつ使い、いつ使わないか

DDDと他のアプローチの比較

DDDは万能薬ではありません。プロジェクトの特性に応じて、よりシンプルなアプローチが適切な場合も多くあります。 まずはDDDと代表的な設計アプローチを比較し、それぞれの適用領域を明確にしましょう。

DDD vs トランザクションスクリプト

トランザクションスクリプトはMartin Fowlerが『Patterns of Enterprise Application Architecture（PoEAA）』で紹介したパターンで、 1つのビジネスオペレーションを1つの手続き（スクリプト）として記述します。 最もシンプルな設計アプローチであり、CRUDが中心のアプリケーションでは十分に機能します。

// トランザクションスクリプト: 手続き的に記述
async function transferMoney(
  fromAccountId: string,
  toAccountId: string,
  amount: number
): Promise<void> {
  const from = await db.accounts.findById(fromAccountId);
  const to = await db.accounts.findById(toAccountId);

  if (from.balance < amount) {
    throw new Error('残高不足');
  }

  from.balance -= amount;
  to.balance += amount;

  await db.accounts.update(from);
  await db.accounts.update(to);
  await db.transactions.insert({ fromAccountId, toAccountId, amount });
}

トランザクションスクリプトはシンプルで理解しやすいですが、ビジネスロジックが複雑化すると スクリプト間でロジックが重複し、条件分岐が肥大化してメンテナンスが困難になります。 一方、DDDではビジネスルールがドメインモデルにカプセル化されるため、ロジックの重複が発生しにくくなります。

DDD vs アクティブレコード

アクティブレコードは、データベースのテーブル行をオブジェクトにマッピングし、 そのオブジェクト自身が永続化のメソッド（save()、delete()等）を持つパターンです。 Ruby on RailsのActiveRecordやLaravelのEloquentが代表的な実装です。

アクティブレコードはデータモデルとドメインモデルが1:1で対応する場合にうまく機能しますが、 ドメインモデルとデータモデルが乖離する複雑なビジネスでは限界に達します。 DDDではリポジトリパターンにより永続化を抽象化し、ドメインモデルをデータベース構造から独立させます。

DDD vs データ駆動設計

データ駆動設計は、まずデータベースのER図を設計し、それを起点にアプリケーションを構築するアプローチです。 多くのエンタープライズ開発で伝統的に採用されてきました。

データ駆動設計では「データをどう保存するか」が出発点となりますが、 DDDでは「ビジネスのふるまいをどうモデル化するか」が出発点です。 この違いは、システムが複雑になるほど設計品質に大きな差を生みます。

軽量DDD（DDD-Lite） vs フルDDD

DDDの導入には大きく2つのレベルがあります。戦術的パターンのみを採用するDDD-Liteと、 戦略的設計と戦術的設計の両方を統合するフルDDDです。

graph LR
  subgraph lite[DDD-Lite 戦術的のみ]
    E[エンティティ]
    VO[値オブジェクト]
    AG[集約]
    R[リポジトリ]
  end
  subgraph full[フルDDD 戦略的+戦術的]
    UL[ユビキタス言語]
    BC[Bounded Context]
    CM[コンテキストマップ]
    SD[サブドメイン分析]
    lite
  end

  style lite fill:#1e1e2e,stroke:#3b82f6,color:#fff
  style full fill:#0f0f1e,stroke:#8b5cf6,color:#fff
  style E fill:#3b82f6,stroke:#1d4ed8,color:#fff
  style VO fill:#3b82f6,stroke:#1d4ed8,color:#fff
  style AG fill:#3b82f6,stroke:#1d4ed8,color:#fff
  style R fill:#3b82f6,stroke:#1d4ed8,color:#fff
  style UL fill:#8b5cf6,stroke:#6d28d9,color:#fff
  style BC fill:#8b5cf6,stroke:#6d28d9,color:#fff
  style CM fill:#8b5cf6,stroke:#6d28d9,color:#fff
  style SD fill:#8b5cf6,stroke:#6d28d9,color:#fff

DDD-Liteでは、エンティティ・値オブジェクト・集約・リポジトリといった戦術的パターンをコード内に適用しますが、 ユビキタス言語やBounded Contextといった戦略的設計を省略します。 Vaughn Vernonは「DDD-LiteはフルDDDの約30%の効果しか得られない」と警告しています。

DDDの採用判断フレームワーク

DDDを採用すべきかどうかを判断するために、2ステップの判断フローを提案します。

flowchart TD
  START([プロジェクト開始]) --> Q1{ステップ1:\nドメインの複雑さは高いか？}
  Q1 -->|Yes| Q2{ステップ2:\nビジネス価値は高いか？\n長期メンテナンスが必要か？}
  Q1 -->|No| SIMPLE[シンプルなアプローチ\nトランザクションスクリプト\nアクティブレコード]
  Q2 -->|Yes| FULL[フルDDD\n戦略的設計 + 戦術的設計]
  Q2 -->|No| LITE[DDD-Lite\n戦術的パターンのみ]

  style START fill:#6366f1,stroke:#4f46e5,color:#fff
  style Q1 fill:#f97316,stroke:#ea580c,color:#fff
  style Q2 fill:#f97316,stroke:#ea580c,color:#fff
  style SIMPLE fill:#14b8a6,stroke:#0d9488,color:#fff
  style FULL fill:#8b5cf6,stroke:#6d28d9,color:#fff
  style LITE fill:#3b82f6,stroke:#1d4ed8,color:#fff

ステップ1: ドメインの複雑さを評価する

以下のいずれかに該当する場合、ドメインの複雑さが高いと判断します。

• ビジネスルールが頻繁に変更される
• ドメインエキスパートが「これは複雑だ」と言う
• 条件分岐が多く、エッジケースが豊富
• 複数の部署・組織が関わるプロセスがある
• 規制やコンプライアンスの要件が厳しい

ステップ2: ビジネス価値を評価する

ドメインが複雑であっても、短命なプロトタイプや使い捨てのツールにフルDDDは過剰です。 長期的にメンテナンスが必要で、ビジネスの競争優位に直結するシステムにのみフルDDDを適用します。

モジュラーモノリスファースト戦略

DDDを導入する際、いきなりマイクロサービスに飛びつくのは危険です。 モジュラーモノリスファーストは、DDDのBounded Contextをモノリス内のモジュールとして実装し、 必要に応じて段階的にマイクロサービスへ分離する戦略です。

Sam Newmanは『Building Microservices』の中で「マイクロサービスへの最も安全な道はモジュラーモノリスから始めることだ」と述べています。 Shopifyもこの戦略を採用し、巨大なRailsモノリスをモジュラーモノリスへ移行した後、必要な部分のみマイクロサービスに切り出しています。

// モジュラーモノリスのディレクトリ構造例
src/
├── modules/
│   ├── ordering/          # 注文コンテキスト
│   │   ├── domain/
│   │   ├── application/
│   │   ├── infrastructure/
│   │   └── api/
│   ├── inventory/         # 在庫コンテキスト
│   │   ├── domain/
│   │   ├── application/
│   │   ├── infrastructure/
│   │   └── api/
│   └── shipping/          # 配送コンテキスト
│       ├── domain/
│       ├── application/
│       ├── infrastructure/
│       └── api/
└── shared/                # 共有カーネル（最小限に）
    └── kernel/

モジュラーモノリスの利点は、モジュール間の境界を強制しつつ、デプロイとオペレーションの複雑さを避けられることです。 Bounded Contextの境界が正しく設計されていれば、将来のマイクロサービス化もモジュール単位で行えます。

レガシーシステムへの段階的導入

既存のレガシーシステムにDDDを導入する場合、一度にすべてをリプレースするのは非現実的です。 バブルコンテキストと腐敗防止層（Anti-Corruption Layer: ACL）を使った段階的導入が有効です。

graph LR
  subgraph legacy[レガシーシステム]
    OLD[既存コード\n手続き的・密結合]
  end
  subgraph acl[腐敗防止層 ACL]
    TR[変換・翻訳]
  end
  subgraph bubble[バブルコンテキスト]
    NEW[新DDDモデル\nクリーンな設計]
  end

  OLD <-->|レガシーAPI| TR
  TR <-->|ドメインモデル| NEW

  style legacy fill:#1e1e2e,stroke:#ef4444,color:#fff
  style acl fill:#1e1e2e,stroke:#f97316,color:#fff
  style bubble fill:#1e1e2e,stroke:#22c55e,color:#fff
  style OLD fill:#ef4444,stroke:#dc2626,color:#fff
  style TR fill:#f97316,stroke:#ea580c,color:#fff
  style NEW fill:#22c55e,stroke:#16a34a,color:#fff

バブルコンテキストは、レガシーシステムの中に新しいDDDモデルを「泡」のように作り出すパターンです。 ACLがレガシーとの間の翻訳を担い、新しいモデルがレガシーの概念に汚染されることを防ぎます。

段階的導入の手順は以下の通りです。

1. 最も価値の高いサブドメインを特定する: コアドメインから着手する
2. ACLを設計する: レガシーとの境界を定義し、変換ルールを明確にする
3. バブルコンテキストを構築する: 新しいモデルをクリーンに設計する
4. 段階的に拡大する: 成功を確認しながら次のサブドメインへ展開する
5. レガシーを縮退させる: 新しいコンテキストが安定したら、レガシーの対応部分を廃止する

採用事例

グローバル企業の事例

日本企業の事例

失敗事例: ヘルスケアプラットフォーム1000万ドルの教訓

DDDの採用が失敗するケースも存在します。ある米国のヘルスケアスタートアップでは、 DDDを全面的に採用した結果、1000万ドル以上のコストオーバーランと18ヶ月の遅延が発生しました。

この事例から得られる教訓は明確です。DDDは適用すべき場所を見極め、段階的に導入することが成功の鍵です。

DDDの成功を測る指標

DDDの効果を定量的に評価するために、体系的文献レビュー（Systematic Literature Review: SLR）の結果から主要な指標を紹介します。

導入チェックリスト

DDDの導入を検討する際に確認すべき項目をチェックリストとしてまとめます。

前提条件の確認

• ドメインエキスパートへのアクセスが確保できるか
• 経営層がDDDへの投資（学習時間・初期の開発速度低下）を理解しているか
• チームにDDDの経験者（または外部コーチ）がいるか
• イテレーティブな開発プロセス（アジャイル）が採用されているか

スコープの定義

• コアドメイン・サポーティングドメイン・ジェネリックドメインの分類ができているか
• フルDDDを適用するBounded Contextが明確か
• パイロットプロジェクト（小さな成功を実証する対象）が特定されているか

チームの準備

• チーム全員がDDDの基本概念を学習したか
• ユビキタス言語の用語集（Glossary）を作成したか
• イベントストーミングのワークショップを実施したか
• 技術スタックがDDDパターンの実装を支援するか