domain-driven-design - 核心域可以跨越多个有界上下文吗？

Question

1)

埃文的书，第。 415:

Also, the critical aspects of the domain model may span multiple Bounded Contexts, but by definition these distinct models can't be structured to show their common focus.

a) 我认为引用暗示核心域 光盘 可以跨越多个有界上下文 BC ?

b) 我假设 BC 内 光盘 应该只包含核心元素，而不包含通用元素？如果是这样，那是不是意味着我们应该总是设计 BC (那些包含在 CD 中)考虑到核心域？换句话说，我们应该对什么是 有一些大致的了解。光盘 甚至在我们开始设计之前 BC ?

C)

... but by definition these distinct models can't be structured to show their common focus

我意识到 BC 不应该这样构建，以便外部世界能够立即弄清楚所有部分(即 BCs )如何组合在一起以及它们的共同目的是什么，但作者暗示这样的结构(这将隐含地传达了不同 BC 的共同目的)即使是偶然也不会发生？如果是这样，为什么？

2)域模型可能有多个通用子域 GS ，但可以单个 GS 跨多个 BC ?

更新:

1)

b)

I assume BCs within CD should only contain core elements, but no generic elements? ...

人们当然应该知道核心域是什么时候
定义 BC。如上所述，理想情况下，它们应该是一对一的。然而，一个
BC 可以被定义为满足系统在非理想情况下的需求
状态。

我假设您是在暗示在非理想情况下 公元前 内 光盘 也可能包含一些非核心元素，也可能在非理想情况下 光盘 可能包含多个 公元前 ?

C)

A domain spans multiple BCs but despite explicit boundaries, domain behavior can certainly span BCs. A context map can describe such cross-BC interactions. The quote itself is based around the idea of a domain vision statement the purpose of which is to highlight the value of the core domain and possibly explain the relationship to BCs.

但是为什么作者使用术语“根据定义”，好像暗示没有办法 BC 是否也可以意外地进行结构化以显示他们的共同关注点？

2)

Domain Model may have several Generic Subdomains GSs , but can a single GS span multiple BCs?

多个 BC 可以使用单个通用子域。我会
在这里避免使用“跨度”一词，因为它过分强调了重要性
整个域模型的通用子域。

一种)

Multiple BCs can make use of a single generic sub-domain

不确定我是否理解您的回复。你是说单 GS 可以包含多个*BC*？

b)

I would avoid the term "spans" here because that overemphasizes the importance of the generic sub-domain for the entire domain model.

也许是一个无用的问题，但您能否详细说明为什么使用术语“跨度”会使通用子域看起来比实际更重要？

回复 Giacomo Tesio:

1)

b)

No, some generic elements often play a key role in the Core Domain. See for example Time, Currency and Money that are present in many Shared Kernel: they are really generic but important to the Core Domain rules.

因此，如果通用元素(例如 Time、Currency 和 Money)是 还有核心域使用，那么只有实现选项是共享内核(即这个通用元素由核心域和任何其他需要它的子域共享)，但如果使用通用元素 只有通过 Core Domain，那么我们不应该为 Shared Kernel 烦恼，而是应该直接在 Core Domain 中定义这个通用元素？

1)

c) Context boundaries are defined after term's semantics. In a BC, no term should mean more than one thing (see SRP). When you see that a class has more than one meaning in the domain expert's mind, you know that you have mixed differnt BC.

您能否稍微扩展一下您的答案，因为我不明白您的答案与我的问题有何关联？

第二次更新:

1)

b)

It may also be that a single BC contains multiple sub-domains. This is usually not ideal because it likely indicates a conflated BC.

在阅读本书时，我并没有太注意作者对“子域”一词的使用，但我很确定这本书没有提供子域是什么的彻底定义。那么究竟什么被认为是子域？只是一堆逻辑相关的领域概念？如果是，那么我假设一个子域不应该跨越多个 BC ?

2)

一种)

A signle GS can be used by multiple BCs. This is so because the sub-domain is generic. So the GS doesn't contain the BCs; instead, it is referenced by the BCs.

从您的回复来看，您似乎暗示通用子域从未实现为 BC ?为什么不呢，因为在我看来不同的通用子域可能包含不同的模型和 BC 似乎是分离这些通用模型的理想解决方案？!

3)
你能不能帮我解决以下问题，因为它让我很困惑:如果通用元素(例如时间、货币和金钱)是 还有核心域使用，那么只有实现选项是共享内核(即这个通用元素由核心域和任何其他需要它的子域共享)，但如果使用通用元素 只有通过 Core Domain，那么我们不应该为 Shared Kernel 烦恼，而是应该直接在 Core Domain 中定义这个通用元素？

谢谢

Answer 1

1a) 在该引文中，作者指的是整个域，而不是核心域。整个域可以跨越多个 BC。 BC 和核心域之间的关系可能更复杂。域、子域和核心域是问题空间的元素。 BC 是解空间的工件。实际上，它们可能并不总是一对一的，但这是理想的。

1b) 在定义 BC 时，人们当然应该了解核心域是什么。如上所述，理想情况下，它们应该是一对一的。但是，可以定义 BC 来满足处于非理想状态的系统的需求。

1c) 一个域跨越多个 BC，但尽管有明确的边界，但域行为肯定可以跨越 BC。上下文映射可以描述这种跨 BC 交互。引述本身基于领域愿景陈述的想法，其目的是突出核心领域的值(value)，并可能解释与 BC 的关系。

2) 多个 BC 可以使用单个通用子域。我在这里避免使用术语“跨度”，因为它过分强调通用子域对整个域模型的重要性。

更新

1b) 核心域可能是用多个有界上下文实现的。这不一定是缺陷，在某些情况下是理想的。也可能单个 BC 包含多个子域。这通常不是理想的，因为它可能表明混合了 BC。

1c) 根据定义，BC 是物理分区的，不应该有直接的依赖关系。我想这就是作者所指的。他强调的问题是，您可以有多个 BC，这需要解释，尤其是在解决单个子域时。

2a) 一个信号 GS 可以被多个 BC 使用。这是因为子域是通用的。所以 GS 不包含 BC；相反，它被 BC 引用。

2b)具有通用子域“跨度”系统可能表明它实际上不是通用子域，而是核心域。这并不是说不能在整个系统中使用通用组件，恰恰相反。然而，在这种情况下，跨越系统的组件只是一个技术轴。

更新 2

1b) 是的，子域是整个域的一个有凝聚力的组成部分。一个子域可以跨越多个 BC。这是可以接受的，因为 BC 是解决方案空间工件，它的存在可能存在技术原因甚至组织问题。例如，在线零售商的域中有一个产品目录子域。这将有一个相应的产品BC。但是，可以将有关产品搜索的附加功能置于产品搜索 BC 中。这仍然是目录子域的一部分，但由于技术原因是一个新的 BC。另一方面，当单个 BC 包含多个子域时，这可能会出现问题。

2a)我认为我对跨度这个词的使用过于语义化。通用子域可以是 BC。但是，必须注意确保通用子域实际上以通用方式使用。

3) 是的。除此之外，像 Money 这样的基类可以为每个子域单独实现，即使它们在多个地方使用。有时复制粘贴是最好的模式。