「コンテキストマップ（Context Map）」は、ドメイン駆動設計（DDD：Domain-Driven Design）において複数の境界づけられたコンテキスト（Bounded Context）間の関係性を可視化するための重要な設計ツールです。
大規模で複雑なシステムを設計・開発する際に、チームとシステムの全体像を把握するために活用されます。
本記事では、コンテキストマップの概念・構成要素・作成手順・活用方法を詳しく解説していきます。
コンテキストマップとは何か？DDDにおける位置づけ
それではまず、コンテキストマップのDDDにおける位置づけと基本概念について解説していきます。
コンテキストマップとは、複数の境界づけられたコンテキスト（Bounded Context）とその間の統合関係・依存関係・チームの関係性を図として可視化したものです。
ドメイン駆動設計（DDD）はエリック・エヴァンスが2003年の著書「Domain-Driven Design」で提唱したソフトウェア設計の思想・手法体系であり、その中でコンテキストマップは「戦略的設計（Strategic Design）」の主要な成果物として位置づけられています。
「境界づけられたコンテキスト（Bounded Context）」とは、特定のドメインモデル・ユビキタス言語（共通言語）が通用する明確な境界を持つサブシステム・サービスのまとまりであり、現代のマイクロサービスアーキテクチャの設計単位とも密接に対応しています。
コンテキストマップは複数の境界づけられたコンテキストの間で「どのように情報が流れ・どのような依存関係があり・チーム間の力関係はどうなっているか」を俯瞰的に把握するための地図として機能するのです。
境界づけられたコンテキストとは？
コンテキストマップを理解するうえで「境界づけられたコンテキスト（Bounded Context）」の概念を正確に把握することが前提となります。
大規模なシステムでは、同じ言葉でも部門・チーム・サブシステムによって異なる意味で使われることがあります。例えば「顧客（Customer）」という概念も、「営業システム」では見込み客を含む広い意味を持ち、「請求システム」では支払い済みの取引先のみを指すかもしれません。
境界づけられたコンテキストは、この「言葉の意味が一貫して通用する領域」に明確な境界線を引くことで、コンテキストごとに独立したドメインモデルを持ち、整合性を保ちながらシステムを設計するための概念です。
マイクロサービスアーキテクチャでは、各マイクロサービスが1つの境界づけられたコンテキストに対応することが理想的な設計とされており、DDDの戦略的設計はマイクロサービスの境界設計の理論的根拠となっています。
境界づけられたコンテキストを特定し、その間の関係を可視化したものがコンテキストマップであり、複雑な大規模システムの全体アーキテクチャを把握するための不可欠なツールなのでしょう。
コンテキストマップに登場する主な統合パターン
コンテキストマップでは、境界づけられたコンテキスト間の関係を表すためにいくつかの標準的なパターン（関係パターン）が定義されています。
「上流（Upstream）/下流（Downstream）」の関係では、上流のコンテキストの変更が下流のコンテキストに影響を与えます。上流が「供給者」・下流が「消費者」という力関係を表します。
「顧客/供給者（Customer/Supplier）」パターンでは、下流チームが上流チームに対して要件を交渉できる協力的な関係を示します。
「順応者（Conformist）」パターンでは、下流チームが上流チームのモデルに完全に従う（交渉力がない）ことを示します。
「腐敗防止レイヤー（Anti-Corruption Layer, ACL）」は、外部システムや上流コンテキストの不完全なモデルから自分たちのドメインモデルを守るための変換レイヤーを表します。
「共有カーネル（Shared Kernel）」は、複数のコンテキストが共有するコードやデータモデルを表し、共有部分の変更は関係するチーム全員の合意が必要です。
| 統合パターン | 意味 | 適用場面 |
|---|---|---|
| 顧客/供給者 | 協調的な上流・下流関係 | チーム間に交渉力がある場合 |
| 順応者 | 下流が上流に完全に従う | 外部サービス・レガシーシステム |
| 腐敗防止レイヤー | 外部モデルからの保護 | レガシー統合・外部API連携 |
| 共有カーネル | 共有コード・モデル | 密結合チーム間の共通部分 |
| 公開ホストサービス | 汎用APIとしての公開 | 多くの下流コンテキストへの統合 |
コンテキストマップの作成手順と活用方法
続いては、コンテキストマップの実際の作成手順と活用方法について解説していきます。
コンテキストマップの作成は段階的なプロセスを経て行われます。
コンテキストマップの作成ステップ
コンテキストマップを作成するための基本的な手順を順番に確認していきましょう。
ステップ1として、現在のシステムに存在する境界づけられたコンテキスト（またはその候補）を特定します。既存のシステム・チーム・データベース・サービスの区分が出発点となります。
ステップ2として、各境界づけられたコンテキストを楕円・長方形などの図形として描き、コンテキスト名を記入します。
ステップ3として、コンテキスト間のデータ・APIの連携関係を矢印で描き、各関係に統合パターン（顧客/供給者・腐敗防止レイヤー等）のラベルを付与します。
ステップ4として、各コンテキストを担当するチームを図に追加し、チーム間の関係・組織構造を反映させます。
ステップ5として、作成したコンテキストマップをアーキテクト・開発チーム・ビジネス関係者でレビューし、認識の齟齬を解消・修正します。
コンテキストマップは一度作成したら完成ではなく、システムの進化・組織の変化・新サービスの追加などに伴って継続的に更新していく「生きているドキュメント」として管理することが重要です。古くなったコンテキストマップは誤った設計判断の元となるため、定期的なレビューと更新のサイクルをチームのプラクティスとして確立することを強くお勧めします。
コンテキストマップの実践的な活用方法
コンテキストマップは設計書としてだけでなく、様々な実践的な場面で活用できます。
アーキテクチャ議論の共通言語として活用することで、技術者・アーキテクト・ビジネス担当者が同じ図を見ながらシステムの全体像を議論でき、認識の齟齬を防ぐことができます。
マイクロサービス分割の設計指針として、コンテキストマップで特定した境界づけられたコンテキストをマイクロサービスの候補として使用することで、適切な粒度での分割設計が可能になります。
チーム構造・組織設計への応用として、コンウェイの法則（「システムの設計構造は、それを設計した組織のコミュニケーション構造を反映する」）に従い、コンテキストマップの構造をチームの境界・責任範囲の設計に反映させることが推奨されます。
技術的負債・リファクタリング計画への活用として、コンテキストマップ上の「不適切な統合パターン（例：すべてのコンテキストが同じDBを共有している状態）」を可視化することで、改善が必要な箇所の優先付けに役立てることができるでしょう。
まとめ
本記事では、コンテキストマップの概念・DDDにおける位置づけ・境界づけられたコンテキスト・統合パターン・作成手順・活用方法について解説しました。
コンテキストマップはDDDの戦略的設計における核心的な成果物であり、大規模システムの複数のサブシステム間の関係性を可視化し、チーム・組織・技術的な意思決定の共通言語として機能します。
マイクロサービスアーキテクチャの普及とともにDDDの重要性が再評価されている現代において、コンテキストマップは複雑なシステム設計を成功に導くための不可欠なツールとなっているでしょう。
