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