コンテキストマップ
他のチームに所属する人々は、コンテキストの境界をあまり意識せず、境目をぼかしたり相互の接続を複雑にしたいする変更を、そうとは知らずに加えるかもしれない。別々のコンテキスト同士を接続しなければならない場合、コンテキストは相互ににじみ出す傾向がある。
境界づけられたコンテキスト間でのコードの再利用は、危険なので避けるべきである。機能とデータの統合は、変換を経て行わなければならない。混乱を減らすためには、別々のコンテキスト同士の関係を定義し、プロジェクトにあるモデルのコンテキストすべてに関する、全体的な視点を作成しなければならない。【中略】
プロジェクトで機能しているモデルをそれぞれ識別して、その境界づけられたコンテキストを定義すること。これには、非オブジェクト指向のサブシステムにある暗黙的なモデルも含まれる。境界づけられたコンテキストそれぞれに名前をつけ、その名前をユビキタス言語の一部にすること。
モデル同士の接点を記述して、あらゆるコミュニケーションで必要となる明示的な変換について概略を述べ、共有するものがアレば強調すること。
まず、「現在存在する」領域の地図を書くこと。変換にはその後でとりかかること。
数十人で開発するシステムの場合、その中でコンテキストが分かれ、チームも分かれる。ただ、コンテキストは違っても、1つのビジョンに向け存在しているシステムのため、相互の接続を行う必要がある。そういう場合、どのようにそのバランスを維持する必要があるか。
それには、まずは全体としてのコンテキストマップをメンバー全員が把握している必要があり、その上で自分たちが行なっているコンテキストはどこで、どのコンテキストとコミュニケーションを取るべきなのかを考え続ける必要があるのではないか。
また、実際のコーディングの場合、どのようにクラスを作成し、その間を相互接続するためのサービスをどう作る必要が有るのか。どれがpublicかprivate（公開して良いクラスかどうか）なのか。それをどう表現するのか。まだその点についてのイメージが湧いていない。もっと深く読み込んでいきたいと思う。
