🗾
概念 #DDD #戦略的設計 #コンテキストマップ #統合 📚 実践ドメイン駆動設計

コンテキストマップ

境界づけられたコンテキスト同士の関係・統合パターンを可視化する戦略的設計ツール

解決する課題

Bounded Context を定義しただけでは、それらがどのように連携するか・どちらが主導権を持つかが不明。コンテキスト間の暗黙の依存が積み重なると、変更が連鎖してシステム全体が硬直化する。

概念

コンテキストマップは、Bounded Context 同士の統合パターンと権力関係を可視化したダイアグラム。「誰が誰に従うか」を明示する。

統合パターン一覧

上流・下流関係（U → D）

上流（U）が変更を加え、下流（D）がそれに適応する。

パターン説明特徴
パートナーシップ2チームが協調してインターフェースを設計高コミュニケーションが前提
共有カーネル一部のモデルを2コンテキストで共有変更にはすべてのチームの同意が必要
顧客と供給者下流（顧客）が上流（供給者）に要件を提示できる定期的なスプリント調整が必要
順応者下流が上流モデルにそのまま従う（交渉不可）上流がサードパーティの場合など

翻訳レイヤー

パターン説明
腐敗防止層（ACL）下流が上流モデルを自分の言語に翻訳するレイヤーを設ける
公開ホストサービス上流が外部向けに安定したAPIを公開する
公表された言語公開ホストサービスが使う、文書化された交換フォーマット（例: JSON Schema）

独立

パターン説明
別々の道統合をあきらめ、それぞれが独立して機能する

なぜ重要か

  • チーム間の権力関係と責任が明文化される（「なぜこのチームの変更を待たないといけないのか」がわかる）
  • 腐敗防止層の必要性が設計上で可視化される
  • マイクロサービス間の依存方向の意思決定根拠になる

腐敗防止層（ACL）の重要性

外部システム（レガシー・サードパーティ）のモデルが自コンテキストに侵食するのを防ぐ翻訳レイヤー。

外部システム → [ACL: 翻訳] → 自コンテキストのモデル

ACL がなければ、外部の変更（カラム名変更・API改変）が自ドメインモデルに直撃する。

背景・思想

コンテキストマップは現実の組織構造とコードを対応させる思想を持つ。Conway の法則（システムの構造は組織の通信構造を反映する）を意識的に設計に取り込む。

関連概念

📚 実践ドメイン駆動設計 15件
  1. 1. 🗺️サブドメイン（コア・サポート・汎用）
  2. 2. 🗾コンテキストマップ
  3. 3. ⬡六角形アーキテクチャ（ポートとアダプター）
  4. 4. 🪪エンティティ（Entity）
  5. 5. ⚙️ドメインサービス（Domain Service）
  6. 6. 📣ドメインイベント（Domain Event）
  7. 7. 🫧集約（Aggregate）
  8. 8. 📐集約の設計原則（Vernon の4ルール）
  9. 9. 🗄️リポジトリ（Repository）
  10. 10. 🏭ファクトリ（Factory）
  11. 11. 📦モジュール（Module）
  12. 12. 🎛️アプリケーションサービス（Application Service）
  13. 13. 🔌境界づけられたコンテキストの統合
  14. 14. ⚡CQRS（コマンドクエリ責任分離）
  15. 15. 📜イベントソーシング（Event Sourcing）

出典: 実践ドメイン駆動設計（Vaughn Vernon）第3章