SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

IDDD本から理解するドメイン駆動設計

実践DDD本 第3章「コンテキストマップ」~「境界づけられたコンテキスト」の関係を俯瞰する地図~

IDDD本から理解するドメイン駆動設計 第3回


  • X ポスト
  • このエントリーをはてなブックマークに追加

 ドメイン駆動設計(DDD)は、顧客と開発者が業務を戦略的に理解し、共通の言葉を用いてシステムを発展させていく開発手法です。第2回の前回は「ドメイン、サブドメイン、境界づけられたコンテキスト」の概要/分割方法/評価方法について紹介しました。第3回となる本稿では、境界づけられたコンテキスト間のチーム関係を示す「コンテキストマップ」について紹介します。

  • X ポスト
  • このエントリーをはてなブックマークに追加

コンテキストマップとは

 「コンテキストマップ」は複数の「境界づけられたコンテキスト」間の関係を俯瞰する地図となり、システムの全体像や相互関係を把握することができます。

IDDD本のサンプルSaaSOvationでの「コンテキストマップ」
IDDD本のサンプルSaaSOvationでの「コンテキストマップ」

 コンテキストマップは「境界づけられたコンテキスト」を丸で囲み、コンテキスト間の関係を線でつなぐシンプルな図です。

 線の終端には「U」と「D」という文字を書きます。UはUpstream(上流)、DはDownstream(下流)を示します。上流/下流とは、あるモデルの変更が他のモデルに影響を与える場合、影響を与える側を「上流」、影響を受ける側を「下流」と呼びます。なお、地図の上側が北を示すように、上流を上に配置すると直感的に理解しやすい図になります。

コンテキストマップを描く理由

 コンテキストマップを描くことによって、システム間の関係を適切に把握できるメリットがあります。DDDチームは既存システムとの連携方法を把握でき、他チームとのコミュケーションの必要性を判断できるようになります。

 コンテキストマップはアーキテクチャ図というよりも、チーム間のコミュケーション関係を示す図の意味合いが強くなります。コンテキストマップは組織間の問題を見つけ出せる唯一のドキュメントとなるため、プロジェクトの成功に不可欠といわれています。

コンテキストマップを書くタイミング

 コンテキストマップは、連携するチームとの関係性を示すドキュメントであるため、なるべく早いうちに作成することが良いとされています。プロジェクトの早い段階からチーム間の関係を正しく認識し、プロジェクト後半のリスクを軽減させます。

 また、コンテキストマップは遠い将来の図ではなく「現時点」の図として記述します。そして機能を追加する時に、随時コンテキストマップを更新します。

コンテキストマップの共有場所

 作成したコンテキストマップは、チームの作業エリアに掲示しておくと良いといわれています(活発なWikiのポータルがあればそこでも構いません)。チームメンバーが常にコンテキストマップを見ながら、オープンな会話ができることが重要となります。

コンテキストマップの書き方

 コンテキストマップの書き方ですが、まず、複数のコンテキストをホワイトボードに書き出します。次に境界づけられたコンテキストが適切に分割されているかを検討し、ユビキタス言語が最適になるように修正していきます。最後に、境界づけられたコンテキストの関係性について「組織パターン」と「統合パターン」を確認していきます。

コンテキストマップの「組織パターン」と「統合パターン」

 コンテキストマップにて、境界づけられたコンテキスト間の関係を描く場合には、大きく次の2種類の分類があります。

  • チーム間の関係を示す「組織パターン」
  • データとプログラムの連携方法を示す「統合パターン」

チームの関係を示す「組織パターン」

 まず、「組織パターン」の4つについて見ていきましょう。

組織パターンの一覧
組織パターンの一覧

(1)パートナーシップ

 2つのチームにおいて協力的な関係が成り立つ場合を「パートナーシップ」の関係と呼びます。このような状況では、計画から連携試験まで共同でマネジメントを行います。チーム間のインターフェイス部を共に検討し、最適な状態になるよう発展させます。

(2)別々の道

 「別々の道」はその名の通り、コンテキスト間で統合を行わないことを示します。2つの境界づけられたコンテキストにおいて連携するメリットがない場合に両者につながりが無いことを明確に宣言します。

(3)順応者

 2つのチーム間において、上流側が下流側の要望を考慮する必要がない状態を「順応者」の関係と呼びます。上流側は下流側の都合を考慮しないため、下流側チームは「腐敗防止層(後述)」を用意して、上流側モデルの変換処理を行います。

 例えば、TwitterやFacebookのAPIを使用するアプリを開発する場合、APIの変更などがあったとしても、アプリ側で対応するしか無いため、アプリ開発チームとしては「順応者」の関係になります。

(4)顧客/供給者

 2つのチーム間において、上流側が供給側、下流側が顧客となるような関係を「顧客/供給者」の関係と呼びます。上流側チームの成否が下流側チームの成否に影響を大きく与える場合、上流側のチームが下流側のチームに対して適切なサポートを行います。そのため、下流チームの要件も考慮して、上流チームが計画や予算を立案します。

 例えば、スマホで独自アプリケーションを開発する場合、API開発チームは「供給者側(上流側)」となり、アプリ開発チームは「顧客側(下流側)」といえるでしょう。

次のページ
境界づけられたコンテキスト間の連携方法を示す「統合パターン」

この記事は参考になりましたか?

  • X ポスト
  • このエントリーをはてなブックマークに追加
IDDD本から理解するドメイン駆動設計連載記事一覧

もっと読む

この記事の著者

WINGSプロジェクト 青木 淳夫(アオキ アツオ)

WINGSプロジェクトについて>有限会社 WINGSプロジェクトが運営する、テクニカル執筆コミュニティ(代表 山田祥寛)。主にWeb開発分野の書籍/記事執筆、翻訳、講演等を幅広く手がける。2018年11月時点での登録メンバは55名で、現在も執筆メンバを募集中。興味のある方は、どしどし応募頂きたい。著書記事多数。 RSS Twitter: @yyamada(公式)、@yyamada/wings(メンバーリスト) Facebook

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

山田 祥寛(ヤマダ ヨシヒロ)

静岡県榛原町生まれ。一橋大学経済学部卒業後、NECにてシステム企画業務に携わるが、2003年4月に念願かなってフリーライターに転身。Microsoft MVP for Visual Studio and Development Technologies。執筆コミュニティ「WINGSプロジェクト」代表。主な著書に「独習シリーズ(Java・C#・Python・PHP・Ruby・JSP&サーブレットなど)」「速習シリーズ(ASP.NET Core・Vue.js・React・TypeScript・ECMAScript、Laravelなど)」「改訂3版JavaScript本格入門」「これからはじめるReact実践入門」「はじめてのAndroidアプリ開発 Kotlin編 」他、著書多数

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

この記事は参考になりましたか?

この記事をシェア

  • X ポスト
  • このエントリーをはてなブックマークに追加
CodeZine(コードジン)
https://codezine.jp/article/detail/9837 2018/11/14 12:22

おすすめ

アクセスランキング

アクセスランキング

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング