コンテキストマップとは
「コンテキストマップ」は複数の「境界づけられたコンテキスト」間の関係を俯瞰する地図となり、システムの全体像や相互関係を把握することができます。
コンテキストマップは「境界づけられたコンテキスト」を丸で囲み、コンテキスト間の関係を線でつなぐシンプルな図です。
線の終端には「U」と「D」という文字を書きます。UはUpstream（上流）、DはDownstream（下流）を示します。上流／下流とは、あるモデルの変更が他のモデルに影響を与える場合、影響を与える側を「上流」、影響を受ける側を「下流」と呼びます。なお、地図の上側が北を示すように、上流を上に配置すると直感的に理解しやすい図になります。
コンテキストマップを描く理由
コンテキストマップを描くことによって、システム間の関係を適切に把握できるメリットがあります。DDDチームは既存システムとの連携方法を把握でき、他チームとのコミュケーションの必要性を判断できるようになります。
コンテキストマップはアーキテクチャ図というよりも、チーム間のコミュケーション関係を示す図の意味合いが強くなります。コンテキストマップは組織間の問題を見つけ出せる唯一のドキュメントとなるため、プロジェクトの成功に不可欠といわれています。
コンテキストマップを書くタイミング
コンテキストマップは、連携するチームとの関係性を示すドキュメントであるため、なるべく早いうちに作成することが良いとされています。プロジェクトの早い段階からチーム間の関係を正しく認識し、プロジェクト後半のリスクを軽減させます。
また、コンテキストマップは遠い将来の図ではなく「現時点」の図として記述します。そして機能を追加する時に、随時コンテキストマップを更新します。
コンテキストマップの共有場所
作成したコンテキストマップは、チームの作業エリアに掲示しておくと良いといわれています（活発なWikiのポータルがあればそこでも構いません）。チームメンバーが常にコンテキストマップを見ながら、オープンな会話ができることが重要となります。
コンテキストマップの書き方
コンテキストマップの書き方ですが、まず、複数のコンテキストをホワイトボードに書き出します。次に境界づけられたコンテキストが適切に分割されているかを検討し、ユビキタス言語が最適になるように修正していきます。最後に、境界づけられたコンテキストの関係性について「組織パターン」と「統合パターン」を確認していきます。
コンテキストマップの「組織パターン」と「統合パターン」
コンテキストマップにて、境界づけられたコンテキスト間の関係を描く場合には、大きく次の2種類の分類があります。
- チーム間の関係を示す「組織パターン」
- データとプログラムの連携方法を示す「統合パターン」
チームの関係を示す「組織パターン」
まず、「組織パターン」の4つについて見ていきましょう。
（1）パートナーシップ
2つのチームにおいて協力的な関係が成り立つ場合を「パートナーシップ」の関係と呼びます。このような状況では、計画から連携試験まで共同でマネジメントを行います。チーム間のインターフェイス部を共に検討し、最適な状態になるよう発展させます。
（2）別々の道
「別々の道」はその名の通り、コンテキスト間で統合を行わないことを示します。2つの境界づけられたコンテキストにおいて連携するメリットがない場合に両者につながりが無いことを明確に宣言します。
（3）順応者
2つのチーム間において、上流側が下流側の要望を考慮する必要がない状態を「順応者」の関係と呼びます。上流側は下流側の都合を考慮しないため、下流側チームは「腐敗防止層（後述）」を用意して、上流側モデルの変換処理を行います。
例えば、TwitterやFacebookのAPIを使用するアプリを開発する場合、APIの変更などがあったとしても、アプリ側で対応するしか無いため、アプリ開発チームとしては「順応者」の関係になります。
（4）顧客／供給者
2つのチーム間において、上流側が供給側、下流側が顧客となるような関係を「顧客／供給者」の関係と呼びます。上流側チームの成否が下流側チームの成否に影響を大きく与える場合、上流側のチームが下流側のチームに対して適切なサポートを行います。そのため、下流チームの要件も考慮して、上流チームが計画や予算を立案します。
例えば、スマホで独自アプリケーションを開発する場合、API開発チームは「供給者側（上流側）」となり、アプリ開発チームは「顧客側（下流側）」といえるでしょう。
