1）
エヴァンの本、ページ。415：
また、ドメインモデルの重要な側面は、複数の境界コンテキストにまたがる場合がありますが、定義上、これらの個別のモデルは、共通の焦点を示すように構造化することはできません。
a）引用は、コアドメイン CDが複数のバウンドコンテキスト BCにまたがることができることを示唆していると思いますか？
b）CD内のBCにはコア要素のみが含まれ、一般的な要素は含まれないと思いますか？もしそうなら、それは私たちが常にコアドメインを念頭に置いてBC （ CDに含まれているもの）を設計する必要があるという意味ではありませんか？言い換えれば、BCの設計を開始する前でも、 CDとは何かという一般的な考えを持っている必要がありますか？
c）
...しかし、定義上、これらの別個のモデルは、共通の焦点を示すように構造化することはできません
BCは、外の世界がすべての部分（つまり、 BC ）がどのように組み合わされ、それらの共通の目的が何であるかをすぐに理解できるように構造化されるべきではないことを理解していますが、著者はそのような構造（暗黙的に伝達する）を暗示しています異なるBCの共通の目的）は偶然でも起こり得なかったのでしょうか？もしそうなら、なぜですか？
2）ドメインモデルには複数の汎用サブドメイン GSが含まれる場合がありますが、単一のGSが複数の BCにまたがることはできますか？
アップデート：
1）
b）
CD内のBCにはコア要素のみが含まれ、一般的な要素は含まれないと思いますか？..。
BCを定義するときは、コアドメインが何であるかを確実に理解する必要があります。述べたように、理想的には、それらは1対1である必要があります。ただし、BCは、理想的ではない状態のシステムのニーズを満たすように定義される場合があります。
非理想的な状況では、 CD内のBCにもいくつかの非コア要素が含まれている可能性があり、非理想的な状況では、 CDに複数のBCが含まれている可能性があることを示唆していると思いますか？
c）
ドメインは複数のBCにまたがっていますが、明示的な境界にもかかわらず、ドメインの動作は確かにBCにまたがることができます。コンテキストマップは、このようなBC間の相互作用を記述できます。引用自体は、コアドメインの価値を強調し、おそらくBCとの関係を説明することを目的としたドメインビジョンステートメントのアイデアに基づいています。
しかし、なぜ著者は「定義上」という用語を使用しているのでしょうか。まるで、 BCが誤って、共通の焦点を示すように構造化される可能性がないことを意味するのでしょうか。
2）
ドメインモデルには複数の汎用サブドメインGSが含まれる場合がありますが、単一のGSが複数のBCにまたがることはできますか？
複数のBCは、単一の汎用サブドメインを利用できます。ここでは「スパン」という用語を避けます。これは、ドメインモデル全体に対する汎用サブドメインの重要性を強調しすぎるためです。
a）
複数のBCが単一の汎用サブドメインを利用できます
あなたの返事がわかりません。1つの GSに複数の*BC*を含めることができると言っていますか？
b）
ここでは「スパン」という用語を避けます。これは、ドメインモデル全体に対する汎用サブドメインの重要性を強調しすぎるためです。
おそらく役に立たない質問ですが、「スパン」という用語を使用すると、ジェネリックサブドメインが実際よりも重要に見える理由について詳しく説明していただけますか？
Giacomo Tesioへの返信：
1）
b）
いいえ、一部の一般的な要素は、コアドメインで重要な役割を果たすことがよくあります。たとえば、多くの共有カーネルに存在する時間、通貨、およびお金を参照してください。これらは実際には一般的ですが、コアドメインルールにとって重要です。
したがって、汎用要素（Time、Currency、Moneyなど）もコアドメインで使用されている場合、実装オプションは共有カーネルのみです（つまり、この汎用要素はコアドメインとそれを必要とする他のサブドメインの両方で共有されます）、しかし、汎用要素がコアドメインでのみ使用されている場合は、共有カーネルを気にする必要はありません。代わりに、この汎用要素をコアドメイン内で直接定義する必要がありますか？
1）
c）コンテキスト境界は、用語のセマンティクスの後に定義されます。BCでは、用語は複数のことを意味するものであってはなりません（SRPを参照）。ドメインの専門家の心の中でクラスが複数の意味を持っていることがわかると、異なるBCが混在していることがわかります。
あなたの答えが私の質問にどのように関連しているか理解できないので、あなたの答えを少し拡張していただけますか？
2回目の更新：
1）
b）
また、単一のBCに複数のサブドメインが含まれている場合もあります。これは、BCが混同していることを示している可能性があるため、通常は理想的ではありません。
この本を読んでいるとき、著者が「サブドメイン」という用語を使用していることにあまり注意を払っていませんが、この本がサブドメインとは何かを完全に定義していないことは間違いありません。では、正確には何がサブドメインと見なされますか？論理的に関連するドメインの概念のほんの一群？はいの場合、サブドメインが複数のBCにまたがってはならないと思いますか？
2）
a）
サインルGSは複数のBCで使用できます。これは、サブドメインが汎用であるためです。したがって、GSにはBCは含まれていません。代わりに、BCによって参照されます。
あなたの回答から、あなたはジェネリックサブドメインがBCとして決して実装されていないことを暗示しているようですか？私の意見では、異なるジェネリックサブドメインには別個のモデルが含まれている可能性があり、BCはそれらのジェネリックモデルを分離するための理想的なソリューションのように思われるので、なぜですか？！
3）私をかなり混乱させるので、次の質問についても助けてもらえますか？ジェネリック要素（Time、Currency、Moneyなど）もコアドメインで使用されている場合、実装オプションは共有カーネル（つまり、このジェネリック）のみです要素はコアドメインとそれを必要とする他のサブドメインの両方で共有されます）が、汎用要素がコアドメインでのみ使用される場合は、共有カーネルを気にする必要はありませんが、代わりにこの汎用要素をコア内で直接定義する必要がありますドメイン？
ありがとうございました