3

我一直在阅读 Eric Evans 的 DDD：Tackling Complexity in the Heart of the Software 和上下文映射部分，Evans 引用了一个使用翻译器集成它们的 2 个有界上下文（预订上下文和网络遍历服务）的示例。

如果我理解正确，当我们创建模型时，我们将所有内容放入有界上下文中，为领域创建概念边界。我的问题是：

  1. 如果一切都应该在有限的上下文中，那么翻译器应该位于哪里？在 Evans 的示例图中，翻译器位于两个有界上下文之外（介于两者之间）。

  2. 假设我们有一个团队在开发 ERP。应该将 ERP 置于多个有界上下文中还是仅置于单个上下文中。基于 Evans 的示例，设计了有界上下文，以便多个团队可以在他们自己的模型上工作。但既然这是一个团队，他们难道不会从单一模型中受益，因此集成不会成为问题吗？还是我理解错了？

  3. 在问题 2 的情况下，如果有多个有界上下文，如果在实现中，我们需要会计中的一个类在工资单中使用怎么办？我认为我们在这里不需要翻译，但我不确定如何分享所需的课程。只从另一个有界上下文中引用所需的类就可以了吗？

  4. 最后，DDD 中的模块如何与有界上下文相关联？

4

2 回答 2

5

  1. 在基础设施层（域外），这是一个技术细节。

  2. 有界上下文（BC）从域中出现，这就是我们识别它们而不是定义它们的原因。一旦确定，如果有许多 BC 并且有可用的开发人员，则可以拆分工作负载，以便更快地开发应用程序。单个模型是不可取的，您需要每个 BC 的单个域模型以及用于查询的简化读取模型 (CQRS)。

  3. 我不知道，但对我来说工资单是会计的一部分，实际上并不存在 2 BC。帐户是 BC，但其他 BC 可能需要工资单，但该定义特定于 BC。并且可能定义实际上只是一些数据（读取模型）。工资单行为应保留在会计中。因此，您需要明确定义每个 BC 对“工资单”的理解。通常，您将拥有一个域服务，该服务将使用来自 BC 的概念并使用“翻译器”。

  4. 它不是。模块只是从技术角度将事物组合在一起。BC 是相当虚拟的，您可能会选择拥有与一个 BC 对应的项目或模块，但如何组织事物由您决定。

于 2014-05-08T16:11:03.137 回答
0
  1. 如果一切都应该在有限的上下文中，那么翻译器应该位于哪里？在 Evans 的示例图中，翻译器位于两个有界上下文之外（介于两者之间）。

我觉得这个问题没有意义。每个 BC 是一个域模型存在的边界，边界由 UL 确定，每个 BC 都有自己的 UL。如果您只创建一个模型，则不需要翻译。您不是将一个大模型分成几个较小的模型，而是加入它们。

  1. 假设我们有一个团队在开发 ERP。应该将 ERP 置于多个有界上下文中还是仅置于单个上下文中。基于 Evans 的示例，设计了有界上下文，以便多个团队可以在他们自己的模型上工作。但既然这是一个团队，他们难道不会从单一模型中受益，因此集成不会成为问题吗？还是我理解错了？

我想你理解错了。您根据 UL 将单个模型拆分为多个 BC，而不是可用团队。然后，如果您没有足够的团队来满足创建的 BC 数量，那么一个团队将不得不开发多个 BC。顺便说一句，相反的情况是不可取的，即不应该由多个团队开发 BC。

  1. 在问题 2 的情况下，如果有多个有界上下文，如果在实现中，我们需要会计中的一个类在工资单中使用怎么办？我认为我们在这里不需要翻译，但我不确定如何分享所需的课程。只从另一个有界上下文中引用所需的类就可以了吗？

您不应该引用另一个 BC 的域对象。BC 应该保护它的域模型，这就是应用层。应用层暴露了 DTO，普通对象，它不应该将域模型暴露给外界。您要求的是共享内核（其他 BC 共享的模型）。

  1. 最后，DDD 中的模块如何与有界上下文相关联？

模块只是一个 java 包，用于将彼此相关的事物组合在一起。因此，您将 BC 的源代码拆分为模块。根据 UL 进行，而不是技术方面。例如，每个聚合的模块，而不是实体的模块，存储库的另一个模块等。

于 2017-10-22T16:16:42.387 回答