g_b*_*g_b 3 domain-driven-design bounded-contexts
我一直在阅读 Eric Evans 的 DDD: Tackling Complexity in the Heart of the Software 和上下文映射部分，Evans 引用了一个使用翻译器将它们集成的 2 个有界上下文（预订上下文和网络遍历服务）的示例。
如果我理解正确的话，当我们创建模型时，我们会将所有内容放入有界上下文中，为域创建概念边界。我的问题是：
如果一切都应该在一个有界上下文中，那么翻译器应该位于哪里？在 Evans 的示例图中，翻译器位于两个有界上下文之外（介于两者之间）。
假设我们有一个团队在处理 ERP。ERP 应该放在几个有界上下文中还是只放在一个有界上下文中。根据 Evans 的样本，设计了有界上下文，以便多个团队可以在自己的模型上工作。但既然这是一个团队，他们会不会受益于单一模型，因此集成不会成为问题？还是我理解错了？
在问题 2 的情况下，如果有多个有界上下文，如果在实现中，我们需要一个来自 Accounting 的类在 Payroll 中使用怎么办？我认为我们在这里不需要翻译，但我不确定如何分享所需的课程。仅从另一个有界上下文中引用所需的类就可以了吗？
最后，DDD 中的模块如何与有界上下文相关？
在基础设施层（域外），这是一个技术细节。
有界上下文（BC）从域中出现，这就是我们识别它们而不是定义它们的原因。一旦确定，如果有很多 BC 并且有可用的开发人员，则可以拆分工作负载，以便更快地开发应用程序。单个模型是不可取的，您需要每个 BC 的单个域模型以及用于查询的简化读取模型 (CQRS)。
我不知道，但对我来说，工资单是会计的一部分，实际上没有 2 BC。帐户是 BC，但其他 BC 可能需要工资单，但该定义特定于 BC。可能定义只是一些数据（读取模型）。薪资行为应保留在会计中。所以你需要清楚地定义每个BC对“工资单”的理解。通常，您将拥有一个域服务，该服务将使用来自 BC 的概念并使用“翻译器”。
不是。模块只是从技术角度将事物组合在一起。BC 是相当虚拟的，您可以选择与一个 BC 相对应的项目或模块，但这是您决定如何组织事物。