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 时，当然应该对核心域是什么有所了解。如前所述，理想情况下，它们应该是一对一的。但是，可以定义 BC 来满足处于非理想状态的系统的需要。
我假设您是在暗示，在非理想情况下，CD中的BC也可能包含一些非核心元素，并且在非理想情况下，CD可能包含多个BC？
C）
一个域跨越多个 BC，但尽管有明确的边界，域行为当然可以跨越 BC。上下文映射可以描述这种跨 BC 交互。引用本身是基于域愿景声明的概念，其目的是突出核心域的价值并可能解释与 BC 的关系。
但是为什么作者使用“按定义”这个词，好像是在暗示BC不可能偶然也被构造成它们会显示出它们的共同焦点？
2)
Domain Model 可能有几个 Generic Subdomains GSs ，但是一个 GSs 可以跨越多个 BCs 吗？
多个BC可以使用单个通用子域。我会在这里避免使用“跨度”一词，因为这过分强调了通用子域对整个域模型的重要性。
一个）
多个 BC 可以使用单个通用子域
不确定我是否理解您的回复。你是说一个GS 可以包含多个*BCs*？
b)
我会在这里避免使用“跨度”一词，因为这过分强调了通用子域对整个域模型的重要性。
也许是一个无用的问题，但您能否详细说明为什么使用“跨度”一词会使通用子域看起来比实际更重要？
回复贾科莫·泰西奥：
1)
b)
不，一些通用元素通常在核心域中发挥关键作用。例如，参见许多共享内核中存在的时间、货币和金钱：它们确实是通用的，但对核心域规则很重要。
因此，如果Core Domain也使用通用元素（例如 Time、Currency 和 Money），那么唯一的实现选项是Shared Kernel（即，此通用元素由Core Domain和任何其他需要它的子域共享），但是如果泛型元素仅由Core Domain使用，那么我们不应该打扰Shared Kernel，而是应该直接在Core Domain中定义这个泛型元素？
1)
c) 上下文边界在术语语义之后定义。在 BC 中，任何术语的含义都不应超过一件事（参见 SRP）。当您看到一个类在领域专家的心目中具有多个含义时，您就知道您混合了不同的 BC。
您能否扩展您的答案，因为我不明白您的答案与我的问题有何关系？
第二次更新：
1)
b)
也可能是单个 BC 包含多个子域。这通常并不理想，因为它可能表明混合的 BC。
在阅读这本书时，我并没有过多关注作者对“子域”一词的使用，但我很确定这本书并没有对子域是什么提供完整的定义。那么究竟什么是子域呢？只是一堆逻辑相关的领域概念？如果是，那么我假设一个子域不应该跨越多个BC吗？
2)
一个）
一个信号 GS 可以被多个 BC 使用。之所以如此，是因为子域是通用的。所以 GS 不包含 BC；相反，它被 BC 引用。
从您的回复看来，您似乎是在暗示通用子域从未实现为BC？为什么不呢，因为在我看来，不同的通用子域可能包含不同的模型，而BC似乎是分离这些通用模型的理想解决方案？！
3）您能否也帮我解决以下问题，因为这让我很困惑：如果Core Domain也使用通用元素（例如 Time、Currency 和 Money ） ，那么唯一的实现选项是Shared Kernel（即这个通用的元素由Core Domain和任何其他需要它的子域共享），但如果通用元素仅由Core Domain使用，那么我们不应该打扰Shared Kernel，而是应该直接在Core中定义这个通用元素域？
谢谢你