境界づけられたコンテキストを利用した解決手段の作成
from Introducing Domain-Driven Design
特定の問題を解決するためには、関連する情報だけを取り入れるべきである。
そのためには、問題空間 と 解決空間 の区別をつくり、それらを 2 つの異なるものとして扱わなければならない。
具体的には、問題空間の ドメイン のモデル（ドメインモデル）を作成し、ドメインの必要な側面のみを抽出して、それらを解決空間に再作成する。
https://scrapbox.io/files/6684def61ed338001d9c15db.png
解決空間では、問題空間のドメインとサブドメインが、境界づけられたコンテキストにマッピングされる。
それぞれの境界づけられたコンテキストは、それ自体が小さいドメインモデルである
サブシステム などの代わりに境界づけられたコンテキストという言葉を使うのは、ソリューションを設計する際にコンテキストを意識し、境界を意識することに集中するため
なぜコンテキストを意識するのか？
それぞれのコンテキストは、ソリューションにおける何らかの専門的な知識を表しているから
コンテキストの中では、共通の言語を共有し、設計は首尾一貫して統一されている
しかし、コンテキストの外に持ち出された情報は、混乱を招いたり、使い物にならない
なぜ境界づけられているのか？
現実世界ではドメインの境界は曖昧なもの: ドメインをサブドメインに分割する#6684e0b375d04f0000ffd93f
一方、ソフトウェアの世界では、別々のサブシステム間の結合を減らし、それらが独立して進化できるようにしたい
複雑さ を減らして 保守性 を高めるため
そのために、サブシステム間に API を設けたり、共有コードのような依存関係を避けるなど、標準的なソフトウェアの手法を用いる
問題空間のドメインは、常に解決空間のコンテキストと一対一の関係にあるとは限らない。
場合によっては、1 つのドメインが複数の境界づけられたコンテキストに分割されることもある
逆に、複数のドメインが 1 つの境界づけられたコンテキストでモデリングされることもある
e.g. 元々使っているソフトウェアシステムとの統合
ドメインをどのように分割したとしても、それぞれの境界づけられたコンテキストに明確な責任を持たせることが重要。
モデルを実装する際に、境界づけられたコンテキストは何らかの種類のソフトウェアコンポーネントに一対一で対応するため
対応するコンポーネントは、別の DLL やスタンドアロンのサービスとしても実装できるようになる
単なる名前空間としても実装可能
コンテキストを正しく区別する
DDD の最も重要かつ難解なのは、境界づけられたコンテキストを定義することである。
理論ではなく職人芸の世界だが、以下のようなガイドラインもある。
ドメインエキスパートの声に耳に傾ける
同じ言語を共有し、同じ問題に焦点を当ててる場合、同じサブドメイン（境界づけられたコンテキスト）で作業をしている
既存のチームや部門の境界に注目する
企業がドメインとサブドメインをどのように考えているかを示す手がかり
ただし、同じ部署の人がバラバラに仕事をするケースや、逆に異なる部門の人々が密接に協力し合うケースもある
後者の場合、同じドメインで仕事していると考えられる
境界づけられたコンテキストの「境界づけられた」の部分を忘れない
曖昧すぎる境界は境界ではない
良い塀が良い隣人を作る
自律性を目指して設計する
1 つの境界づけられたコンテキストにドメインエキスパートのグループが 2 組関与する場合、設計が進化する過程で、それぞれが別の方向に引き寄せようとしてしまう可能性がある
そのため、境界づけられたコンテキストを分離して自律性を持たせ、個別に進化できるようにしたほうが良い
自律性を求めるのは、パフォーマンスではなく、一定レベルの可用性とサービスにコミットできるようにするため
どうしても自律性を確保することが難しい場合
サービスを信頼する
問題が発生しても対応できるようにしておく
摩擦のないビジネスワークフローを目指して設計する
ワークフローが複数の境界づけられたコンテキストと相互に作用し、それらによってしばしばブロックされたり遅延したりする場合、設計が煩雑になっても、ワークフローがよりスムーズになるようにコンテキストのリファクタリングを検討すべき
設計の様々な「純粋さ」よりも、ビジネスおよび顧客の価値に焦点を当てるべき
そもそも DDD はビジネスに焦点を当てる開発手法である radish-miyazaki.icon
また、ビジネス要件の変化に応じて、時間とともにモデルを進化させる必要がある。
Evolving a Design and Keeping It Clean
コンテキストマップの作成
コンテキストを定義したあとは、設計の詳細に巻き込まれることなく、コンテキスト間の相互作用を伝える方法が必要。
DDD ではこれを コンテキストマップ と呼ぶ
コンテキストマップの目的は、すべての詳細を把握することなくシステムの全体像を示すことである。
https://scrapbox.io/files/6684f1f397f099001d4c94f5.png
2 つのコンテキストは、交換するメッセージの共有フォーマットに同意する必要がある
一般的に上流側（顧客側）のコンテキストがフォーマットに対してより大きな影響力を持つが、下流側（システム側）のコンテキストが柔軟性に欠ける場合もある
e.g. レガシーシステムを使用している場合など
A Functional Architecture
上記の例はシンプルだが、もっと複雑な場合は特定のサブシステムに焦点を当てた、より小さなマップが複数作られる
もっとも重要な境界づけられたコンテキストに焦点を当てる
いくつかのドメインは他のドメインよりも、ビジネスの観点から重要である（コアドメイン）。
コアドメインを見つけるのは難しい
思いもよらないものがコアドメインの可能性も
コアドメイン がなんであれ、重要なのは以下の 2 点。
優先順位を付けること
すべての境界づけられたコンテキストを同時に実装しようとしないこと
もっとも価値のある境界づけられたコンテキストに焦点を当て、そこから広げていく。
それ以外にも、必要不可欠だがコアではないドメインもある（支援ドメイン）。
また、企業固有のものではないドメインもある（汎用ドメイン）。