我一直在阅读 Eric Evans 的 DDD:解决软件核心的复杂性问题，在上下文映射部分中，Evans 引用了一个使用翻译器集成 2 个限界上下文(预订上下文和网络遍历服务)的示例他们。
如果我理解正确的话，当我们创建模型时，我们将所有内容都放入有界上下文中，从而为领域创建概念边界。我的问题是:
如果一切都应该在有界上下文中，那么翻译器应该位于何处？在 Evans 的示例图中，翻译器位于两个限界上下文之外(介于两者之间)。
假设我们有一个团队致力于 ERP。 ERP 应该放在多个限界上下文中还是只放在一个限界上下文中。基于 Evans 的示例，设计了限界上下文，以便多个团队可以在他们自己的模型上工作。但由于这是一个单一的团队，他们难道不会受益于单一模型，因此整合不会成为问题吗？还是我理解错了？
在问题 2 的情况下，如果有多个限界上下文，如果在实现中我们需要一个来自 Accounting 的类用于 Payroll 怎么办？我认为我们这里不需要翻译，但我不确定如何分享所需的类(class)。仅从另一个限界上下文中引用所需的类就可以了吗？
最后，DDD 中的模块如何与限界上下文相关？
最佳答案
在基础设施层(域外)，它是技术细节。
限界上下文 (BC) 从域中出现，这就是我们识别它们而不是定义它们的原因。一旦确定，如果有很多 BC 并且有可用的开发人员，则可以拆分工作负载，以便可以更快地开发应用程序。单一模型是不可取的，您需要每个 BC 一个单一域模型以及一个用于查询的简化读取模型 (CQRS)。
我不知道，但对我来说，薪资是会计的一部分，实际上并没有 2 BC。 Account 是一个 BC，但是其他 BC 可能需要一个 Payroll 但该定义是特定于 BC 的。并且可能定义只是一些数据(读取模型)。薪资行为应保留在会计中。因此，您需要明确定义每个 BC 对“工资单”的理解。通常，您会有一个域服务，它会使用 BC 的概念，并且会使用“翻译器”。
不是。模块只是从技术角度将事物组合在一起。 BC 非常虚拟，您可能会选择一个项目或一个模块与一个 BC 相对应，但这取决于您如何组织事物。
关于domain-driven-design - DDD 中限界上下文之间的转换器(以及其他一些问题)，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/23543622/