DDD中有界上下文之间的翻译器(以及其他一些问题)

Question

我一直在阅读Eric Evans的DDD:解决软件中心和上下文地图部分的复杂性，Evans引用了一个使用翻译来集成它们的有界上下文(预订上下文和网络遍历服务)的例子。

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

1. 如果每件事都应该在一个有限的上下文中，译者应该在哪里？在Evans的示例图中，译者位于两个有界上下文的外部(介于两者之间)。
2. 假设我们有一个团队在ERP上工作。应该将ERP放在几个有限制的上下文中，还是只放在一个上下文中。基于Evans的样本，设计了有界的上下文，以便多个团队能够在自己的模型上工作。但是，由于这是一个单一的团队，他们不会受益于一个单一的模型，所以集成不会成为一个问题吗？还是我理解错了？
3. 在问题2的情况下，如果多个有限制的上下文，如果在实现中，我们需要一个来自会计的类来用于薪资？我不认为我们需要一个翻译，但我不知道如何分享所需的课程。仅仅从另一个有限制的上下文引用所需的类就行了吗？
4. 最后，DDD中的模块如何与有界上下文相关？

Answer 1

1. 在基础设施层(域外)，这是一个技术细节。
2. 一个有限的上下文(BC)出现在领域中，这就是为什么我们识别它们，而不是定义它们。一旦确定，如果有许多BCs和有可用的开发人员，那么工作负载可以被分割，这样应用程序就可以得到更快的开发。单一模型是不可取的，您希望每个BC只需要一个域模型，也需要一个简化的查询模型(CQRS)。
3. 我不知道，但对我来说，工资是会计的一部分，没有真正的公元前两年。帐户是BC，但是其他BC可能需要工资，但是这个定义是特定于BC的。可能定义只是一些数据(读取模型)。工资单行为应留在会计部门。因此，您需要有明确的定义，每个BC理解的“工资”。通常，您将拥有一个域服务，该服务将使用来自BC的概念，而后者将使用“translator”。
4. 不是的，一个模块只是从技术的角度把事情组合在一起。BC是相当虚拟的，您可以选择有一个项目或模块对应于一个BC，但这是您如何组织事情的决定。

Answer 2

1. 如果每件事都应该在一个有限的上下文中，译者应该在哪里？在Evans的示例图中，译者位于两个有界上下文的外部(介于两者之间)。

我觉得这个问题是没有道理的。每个BC是一个域模型存在的边界，边界由UL确定，每个BC都有自己的UL。如果你只创建一个模型，你就不需要翻译了。与其将一个大模型分割成几个小模型，不如加入它们。

1. 假设我们有一个团队在ERP上工作。应该将ERP放在几个有限制的上下文中，还是只放在一个上下文中。基于Evans的样本，设计了有界的上下文，以便多个团队能够在自己的模型上工作。但是，由于这是一个单一的团队，他们不会受益于一个单一的模型，所以集成不会成为一个问题吗？还是我理解错了？

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

1. 在问题2的情况下，如果多个有限制的上下文，如果在实现中，我们需要一个来自会计的类来用于薪资？我不认为我们需要一个翻译，但我不知道如何分享所需的课程。仅仅从另一个有限制的上下文引用所需的类就行了吗？

您不应该引用另一个BC的域对象。BC应该保护它的域模型，这是应用程序层。应用层公开DTO，普通对象，它不应该向外界公开域模型。您所要求的是一个共享内核(一个由其他BC共享的模型)。

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

模块只是一个java包，用于将相互关联的东西放在一起。因此，您将BC的源代码拆分为模块。按照UL来做，而不是技术方面。例如，每个聚合的模块，而不是实体的模块，存储库的模块等等。