はじめに
前回のpart2.1で「境界づけられたコンテキスト」について重点的に解説しました。
というのも、今回の記事で紹介する「コンテキストマップ」は、その名の通り境界づけられたコンテキストと深く関わるものだからです。今回の内容は分割した領域同士の関係についてです。
「コンテキストマップ」とは？
では、解説に入ります。「コンテキストマップ」とは、境界づけられたコンテキスト間の関係を俯瞰する地図のようなもので、システムの全体像や相互関係の把握に利用することができます。
具体的に考えてみましょう。私が参考にした書籍には以下のような図で説明されていました。
ここでは一つ一つの役割については省略します。線の両端にある「U」や「D]はそれぞれ上流（Upstream）、下流（Downstream）を意味します。これは依存関係を表しており、Ｕは「影響を与える側」、Ｄは「影響を受ける側」を表します。
つまり、Ｕでモデルの変更があった場合はＤもその被害を受けるといういことです。
このマップを作ることにより、ＤＤＤの開発チームはもとのシステムとの連携方法や他チームとのコミュニケーションの必要性を把握できるようになります。
コンテキストマップはアーキテクチャ（構造）図としての側面よりもコミュニケーション関係を示す図としての側面の方が大きい。
「組織的パターン」と「統合パターン」
コンテキストマップを書く際には、次の２種類の分類があります。まず、簡単に説明すると下のようになります。
- 組織的パターン
- チームの関係を示す。
- 統合パターン
- データとプログラムの連携方法を示す。
組織的パターン
以下の４つがあります。
- パートナーシップ
- ２つのチームにおいて協力的な関係が成り立つ場合。
計画から連携試験まで共に進めていく。 - 別々の道
- 統合しない。（両者の関係なし。）
- 順応者
- 上流側が下流側の要望を聞かなくてもよい状態。
例：APIに変更があったとき、アプリケーションチームはそれに対応するしかない。 - 顧客、供給者
- 「順応者」と逆のようなもの。上流チームは下流チームの要望も考慮して作業する。
統合パターン
以下の５つがあります。
- 共有カーネル
- 複数ドメインにおいて共有が必要な部分に、共通で使用するドメインモデルを構築してソースコードレベルで共有すること。
変更があったときに他チームの承認が必要になるので極力少なくする。 - 巨大な泥団子
- とても大規模なもともとあったシステムのこと。
チームと連携させるときは自分たちの「境界づけられたコンテキスト」がのみこまれないよう注意する。 - 公開ホストサービス（Open Host Service）
- 「境界づけられたコンテキスト」の内容にアクセスできる公開サービス。
これを利用するクライアントは複数いても問題ない。 - 公表された言語（Published Language）
- ２つの境界づけられたコンテキスト内のモデルを変換する共通の言語（JSONやXML）。
「公開ホストサービス」と組み合わせて使われることが多い。 - 腐敗防止層（Anti-Corruption Layer）
- 先ほどの「順応者」の関係のときに使われる。
下流側のチームは上流側の機能を自コンテキストのドメインモデルとして変換する必要があるため用いられる。データの送受信（２ケース）分のモデル変換を双方向に行う。
おわりに
今回はコンテキストマップについて解説しました。前述したように、これはコミュニケーション図であり、チームで開発を行うのにとても重要なものであることが理解できたと思います。
では、今回はここで終わりとします。最後まで読んでくださり、ありがとうございました。