これまでの十四章
コンテキストマップ
前回まで読んできた境界づけられたコンテキストを各々対応していても混乱しますよね。虫の目だけでなく鳥の目の視点を得ることが必要。
そのためのコンテキストマップ。
例にあるように、手書きで書いてもいいし、Twitterでアドバイスいただいたのは、RDRAのコンテキスト図です。
これを全員が把握すること。
コンテキストマップで鳥の目を得る効果
境界がチーム編成に影響する
境界によるチーム分けはしやすく、結果、近くの人、会話をする人が自然と同じコンテキスト内にいることになるでしょう。
注意点としては、"誰々チーム"という呼び方はせず、コンテキストに名前を付け"○○コンテキスト"と呼ぶこと。名前はユビキタス言語の一部にすることです。
コンテキスト間の接続をする必要があることもあり、その議論のために業務に即したコンテキストの名前を使うことはとても有益です。
分派を発見したときの混乱を避ける
分派が発見され、コンテキストを分けたり、サブシステムに切りわけることになってもコンテキストマップがあれば全体的な視点をもって取り組むことができます。
逆にコンテキストマップがない状態で、こういった問題に取り組むと、変更すべき全容が見えず危険です。
コンテキスト間の接続
コンテキストの名前、コンテキスト間の関係が明らかになれば、あとはどのようにコンテキスト間でやり取りするかという問題になります。
書籍の例では、「経路選択サービス」と「ネットワーク走査サービス」間のモデルを変換する「予約ー運送ネットワークサービス」をコンテキスト間に作成しました。
このような例がこのあと何節かにわたってパターンとして登場しますので読んでいきます。
コンテキスト境界でのテストは重要
別々のチームが接続するので、テストはとても重要。変換するための微妙な差異などの早期発見のためにも重点的にテストを書くのが原則です。
ただ、やることははっきりしているはずのなので、テストを書くこと自体は容易なはずですね。