要約
境界付けられたコンテキストは、次のように階層的に認識すべきだろう。
(1) 複数のステークホルダー同士が一式の業務用語セットを共有している範囲としてのコンテキスト
＊一般に複数のサブドメイン横断的である。
(2) (1)のコンテキストと、サブドメインとのインターセクション（共通部分集合）
＊(1)のコンテキストをサブドメイン毎に切り分けたもの。
(3) (2)のコンテキスト内にて、一つのサブドメインの一つの管理対象に関する複数のモデル＝サブジェクト
＊一つのサブドメインの一つの管理対象についても、例えば参照系主体モデルと更新系主体モデルといったように、複数のモデルが想定される。
◆注意◆
・本記事の内容は独自見解です。DDDの用語を参照、使用していますが、各用語は本記事として独自にアレンジ、再定義しています。本記事はDDDそのものを説明しているものではなく、独自の応用や解釈を述べているものです。
・私の最新の物思いを記しています。本ブログの過去記事と論旨や用語使いが整合していない部分があります。（※一部は記事中にその説明があります。）
〜・〜
（サブ）ドメインとは何か？
（サブ）ドメインとは、何らか業務上の管理対象（＝データ）の存在が認められる時、その管理対象に纏わる“モデル”を所属させる名前空間を、管理対象毎に定義したもの。
例えば、「受注」や「返品」といった（サブ）ドメインが存在する、とします。
境界付けられたコンテキストとは何か？
複数のステークホルダーが、“完全に定義された一式の業務用語セット”（＝ユビキタス言語）をシェアしている時、その業務用語セットが表現し得る語彙空間を、境界付けられたコンテキストと称する。
ここで、おおむね共通の関心事を持っているステークホルダー同士が、一つの業務用語セットをシェアするものだという傾向の存在を意識します。関心事をシェアしていないステークホルダー間では業務用語セットもシェアされないでしょう。
例えば、「販売管理業務に纏わる用語セットとその語彙空間」、「オンライン注文受付サービス業務に纏わる用語セットとその語彙空間」、などが想定できます。
ここには理解の工夫があります。最初に境界付けられたコンテキストを定めて、次にそのコンテキスト内にて適切な用語セットを定義していく、という順序ではありません。用語セットをシェアすることができるような、あるいは既にシェアしているような複数のステークホルダーが共有する関心事空間を見出し定義したものを、境界付けられたコンテキストだと定める、という順序です。業務用語セットの定義と共有を推し進めていって、結果的に共有することができた範囲を以って境界付けられたコンテキストにするのです。
※本来のDDDでは、ユビキタス言語とは、開発者と業務担当者が用語セットをシェアする、という点を強調しています。それは一つの境界付けられたコンテキスト内における話です。本記事では、一つの境界付けられたコンテキスト内にて、開発者と業務担当者を含むすべてのステークホルダーが用語セットをシェアすることは当然として、その先で、複数の境界付けられたコンテキストがあるとき、そのまさに“境界”が如何に線引きされるのか、という点に関心を置いてます。「ユビキタス言語を如何にシェアしていくか」ということではなく、「ユビキタス言語がシェアできない限界を如何に見極めるのか」という点に着目するものです。
境界付けられたコンテキストとサブドメインは一対一か？
レガシーなエンタープライズ・システムでは、両者はほぼ一対一だったものと云えそうです。かつては管理が必要と思われる対象（＝データ）毎に組織編成し、各組織にそのデータのお守りを担わせるという考えがありました。組織に属するメンバー（＝ステークホルダー）の関心事は、その組織が担うところの管理対象でもって分断されていきます。自ずとステークホルダー間でシェアされる用語セットの表現する語彙空間も、管理対象に拠ったものとなるでしょう。
しかし、近年はステークホルダーが共有する関心事の分断パターンが変わってきました。その最右翼が、何度も登場しますが、“Web系”です。Web系のシステムがレガシーなエンプラ・システムと異なる最大の特徴は、最終利用者向けの専用サブシステムが設置される点です。フロントエンドです。ステークホルダーの関心事は、もはや業務上の管理対象観点ではなく、最終利用者向けのシステムか、バックオフィス向けシステムかで分断されます。
※言うなれば、「企業内部の管理都合観点から、顧客提供価値との関係性観点に移行した」ということです。
こうなってくると、（サブドメインとはあくまで管理対象の存在で分割するものだという定義を変えないならば、）サブドメイン分割と境界付けられたコンテキストの分割は、お互いに一致しなくなってきます。もはやn対nの関係性です。
サブドメインと境界付けられたコンテキストの“インピーダンス・ミスマッチ”
（本記事の説明するような）サブドメインと境界付けられたコンテキストとが相互にずれているという様子は、Web系に限らず、近代ではエンプラ系でも普通に認められます。Web系ほど典型的で分かりやすいものは少ないですが、個人の経験的に、システム化対象領域の7〜8割は一対一にみなせますが、2〜3割はずれていると見るべきです。そしてこの2〜3割がコア（サブ）ドメインだったりします。
サブドメインと境界付けられたコンテキストが一対一対応していない様子を、「“インピーダンス・ミスマッチ”がある」と称することとしましょう。
インピーダンス・ミスマッチがあるとき、境界付けられたコンテキストの解釈違いが露呈する
本記事では、境界付けられたコンテキストとは、ステークホルダーの関心事空間を表し、管理対象たるサブドメインとは、n対n対応するものだとしました。本来のDDDでは、境界付けられたコンテキストとは、ある一つのサブドメイン内における複数の観点違いを表していたと思えます。サブドメインと境界付けられたコンテキストとは、1対nの関係性に在るという理解です。
レガシーなエンタープライズ・システムのように、サブドメインと境界付けられたコンテキストとがほぼ一対一対応している場合、境界付けられたコンテキストに関して本記事と本来のDDDとのような解釈違いが有っても、何せ結果的に一対一対応になるので、結果的な境界付けられたコンテキストの認識に差異が出ません。
近代のシステムのように、サブドメインと境界付けられたコンテキストにインピーダンス・ミスマッチが存在するときは、本記事と本来のDDDとのような解釈違いによって、結果的な境界付けられたコンテキストの認識に違いが現れます。
ドメインエキスパートは、隣の境界付けられたコンテキストまでは考慮していない
ドメインエキスパートは（※「ステークホルダーは」に言い換えた方がよいかもしません。）、自分の関心対象たる境界付けられたコンテキストについては、雄弁に語ってくれるでしょう。しかし、関心対象外な境界付けられたコンテキストについては、文字通り関心対象外故何も語ってはくれないでしょう。他の境界付けられたコンテキストについては、別のドメインエキスパートに話を聞かなければなりません。
サブドメインと境界付けられたコンテキストがほぼ一対一であるならば、一つのサブドメイン、つまり一つの管理対象について関心を持って語るドメインエキスパートは一人です。よって、そのドメインエキスパートの語る内容がその管理対象についての全てだと見なして問題にはなりません。サブドメインと境界付けられたコンテキストがn対nの関係でずれた領域をカバーするような場合、一つの管理対象について関心を持っているドメインエキスパートは複数人存在することになります。かつ、その複数人は異なる立ち位置からそれぞれの異なる事実認識を語るでしょう。
一つのサブドメインに複数の境界付けられたコンテキストが被ってくる→ファット・モデルの原因
サブドイメンと境界付けられたコンテキストに“インピーダンス・ミスマッチ”がある領域において、ある一つのサブドメインに注目すると、その一つのサブドメイン対して、複数の境界付けられたコンテキスト＝複数のステークホルダーの異なる関心ごと、が被ってくることとなります。このことがファット・モデルの主な発生要因と考えます。唯一のサブドイメン（＝管理対象）に対して、複数の関心ごとが被ってくるのです。太らないわけが無いのです。
一つの境界付けられたコンテキストに、複数の管理対象が関わる
今度は一つの境界付けられたコンテキストに着目してみると、その一つの境界付けられたコンテキストには、複数のサブドメイン、即ち複数の管理対象が関わってくる事となります。一つの境界付けられたコンテキスト＝ある範囲のステークホルダーが共有している一つの関心事空間にて、複数のサブドメイン＝管理対象を扱うこととなるのです。本記事では、境界付けられたコンテキストとは、定義として、業務用語セットをシェアできている範囲、としたので、用語セットをシェアできている限りにおいて、サブドメインをまたがっても、一つの境界付けられたコンテキストに在ると云って良いとします。境界付けられたコンテキスト内のユビキタス言語は、複数のサブドメインにまたがった語彙空間を展開し得るとしています。複数のサブドメインに跨るということは、プロセスに関する言及を含むということです。
サブドメイン「受注」と「返品」の例で云えば、「フロント」という境界付けられたコンテキスト観点の「受注」と「返品」、「バックオフィス」という境界付けられたコンテキスト観点の「受注」と「返品」が存在することとなります。フロント観点にて（＝フロントの境界付けられたコンテキスト内では）、受注と返品の業務プロセス上の関係性は無矛盾に説明されていることは期待してよいでしょう。同様に、バックオフィス観点でも（＝バックオフィスの境界付けられたコンテキスト内でも）、受注と返品の業務プロセス上の関係性は無矛盾に表現されているでしょう。では、フロントの返品とバックオフィスの返品は、相互に無矛盾に表現されているでしょうか。ユビキタス言語がシェアされて無いので、定義上、無矛盾性は保証されていません。実態としても、事実あやしい（こともある）だろうと想像出来そうな場面です。
境界付けられたコンテキストとサブドメインの公約数的部分集合を捉える
前節の最後の例では、境界付けられたコンテキスト（関心事空間）としてフロントエンドとバックエンドの二つ、それに、サブドメイン（管理対象）として受注と返品の二つが存在するとしました。“インピーダンス・ミスマッチ”が存在するとして、両者掛け合わせて都合4つの部分集合を認識できることとなります。
これらの、境界付けられたコンテキストとサブドメインとによるインターセクションの一つ一つの領域は、境界付けられたコンテキストの部分集合であるので、境界付けられたコンテキストを「大粒度のコンテキスト」、これら公約数的部分集合群を「（相対的に）小粒度のコンテキスト」である、と捉えることにします。
コンテキストの階層的認識と、コンテキストとサブジェクトの関係性について修正定義
本記事では、「フロントエンド」はそれで一つの関心事空間＝境界付けられたコンテキストを構成するとしています。
両方の話をマージすると、「一つの関心事空間に、同一の管理対象に関する複数のサブジェクト（つまりはモデル）が含まれ得る」という主張となります。この見方は、前節における「関心事空間とサブドメインのインターセクション」よりもさらに小粒度な領域だということとなります。
以前の記事では「サブジェクトと境界付けられたコンテキストとは同義である」としました。本記事では次のように捉え直します。まず、いわゆる境界付けられたコンテキストが、一式のユビキタス言語を共有する境界として、最大粒度のコンテキストを構成します。次に、最大粒度のコンテキストには複数のサブドメインについての言及が含まれるので、それぞれが中粒度のコンテキストを成すとします。最後に同一サブドメイン（管理対象）についても異なる複数のサブジェクトが定義され得るので、これを最小粒度のコンテキストだとします。
「境界付けられたコンテキスト」の捉え方には粒度の差があるものとします。「サブジェクト」は、その内の最小粒度のコンテキストに対応するものと位置付けます。
本来のDDDでは、同一の管理対象（＝データ資源）であっても、要求・要件の観点が異なるならば、異なる境界付けられたコンテキストとして異なるモデル設けよ、といっていたかと思われます。この言及は、本記事の用語使いに基づくならば、最小粒度のコンテキスト＝サブジェクトについての言及であると云えます。一方、ユビキタス言語共有境界としてのコンテキストは、本記事としては、そのような「サブジェクト」では小さすぎると考えます。本記事としては、詰まるところ、コンテキストは階層的に認識するべきだろうと考えます。
◆以上
