実践DDD本 第2章「ドメイン」「サブドメイン」「境界づけられたコンテキスト」を読み解く

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

「境界づけられたコンテキスト」とは

　ドメインの課題を解決する部分を「境界づけられたコンテキスト」と呼びます。IDDDでは、1つの「コアドメイン（もしくはサブドメイン）」に、1つの「境界づけられたコンテキスト」が対応している状態が最適だとされています。ただし、現実の（レガシー）システムでは、複数のドメインに対して1つの境界づけられたコンテキストしか存在しないケースも多々存在します。

複数の意味を持つドメイン用語

　ここでは、システムにおける言葉に注目してみましょう。例えば「アカウント」という言葉の場合、業種によって意味が異なってきます。

業種によって異なる「アカウント」の意味

業種	「アカウント」という用語の意味
会計システム	勘定科目
営業管理システム	顧客
コンピューターシステム	ログイン権限

　続けて、同じ商品であってもタイミングで呼び名が変わる「ECサイト」の「商品」の例を見てみましょう。

ECサイトのタイミングに応じた「商品」の呼び名の変化

順番	「商品」の取り扱い状態	「商品」の呼び名
1	予約中	入荷待ち
2	入荷時	着荷品
3	販売中	在庫品
4	販売後	出庫品
5	トラブル発生時	不良品

　「取り扱い状態」の変化によって「商品」の呼び名が変わることがわかると思います。規模が大きいシステムでは、1つの言葉が複数の状態を兼ねてしまうこともあります。しかし、DDDではこのような巨大な「エンタープライズモデル」は設計しません。「アカウント」や「商品」という言語が、2つ以上の意味を持たないように「境界づけられたコンテキスト」を適切に分割し、プログラムの複雑化を防ぎます。

ユビキタス言語を明確にする「境界づけられたコンテキスト」

　前章（1章）にて述べた通り、DDDでは共通言語として「ユビキタス言語」を作り上げ、そのモデルに沿って実装します。そこで、ユビキタス言語の意味が変わる境界で「境界づけられたコンテキスト」を分割して管理します。DDDの「コンテキスト」は「企業や組織の文化」に近い意味を持ちます。つまり「境界づけられたコンテキスト」はユビキタス言語が複数の意味を持たないようにするための明示的な境界と言えます。この戦略的設計を適切に実行すると、異なる概念がドメインに混ざらないため、シンプルなシステムを構築できます。

「境界づけられたコンテキスト」の担当体制

　1つの「境界づけられたコンテキスト」は複数チームではなく、1つのチームだけで担当します。そのためドメインエキスパートは自分の裁量でユビキタス言語を定義し、シンプルなモデルを構築できます。逆に言えば「在籍する多数のドメインエキスパートで認識を統一することは容易ではない」という組織の特性が表れているともいえます。

「境界づけられたコンテキスト」と「ドメインモデル」の設計指針

　「境界づけられたコンテキスト」の分割を行う際は、アーキテクチャ、タスク分担、成果物などの影響を受けないように注意します。例えば、1つの「境界づけられたコンテキスト」が、1つのJARやDLLになるといった制限はありません。また「境界づけられたコンテキスト」に含まれるドメインモデルのクラス数や構成の目安も決まってません。

　ヴァーン氏はIDDD本でモーツァルトの映画のセリフを引用し『素晴らしいドメインモデルは、余計な音もなければ、足りない音もない。調和した交響曲のようなもの』と紹介しています。DDDのチームメンバーはドメインエキスパートによる言語的な境界に注目して、高度な技術と豊かな感性にて「境界づけられたコンテキスト」と「ドメインモデル」を洗練させていきます。

　次ページからは、IDDD本のサンプルを元に、「ドメイン」と「境界づけられたコンテキスト」の分割例について見ていきましょう。