我一直在阅读Eric Evans的DDD：解决软件核心的复杂性以及背景图中的部分，Evans引用了一个使用翻译器集成的2个有界上下文（预订上下文和网络遍历服务）的示例它们。
如果我理解正确，当我们创建模型时，我们会将所有内容放入有界上下文中，为域创建概念边界。我的问题是：
如果一切都应该在有限的背景下，翻译者应该在哪里？在埃文斯的示例图中，翻译者在两个有界的上下文之外（在两者之间）。
假设我们有一个团队致力于ERP。 ERP是应该放在几个有限的上下文中还是仅限于一个上下文中。根据埃文斯的样本，设计了有限的上下文，以便多个团队可以在他们自己的模型上工作。但由于这是一个团队，他们不会在单一模型上受益，因此整合不会成为问题吗？或者我明白这个错了吗？
在问题2的情况下，如果有多个有界上下文，如果在实现中，我们需要一个来自Accounting的类用于Payroll？我认为我们不需要翻译，但我不确定如何分享所需的课程。只是从另一个有界的上下文中引用所需的类就可以了吗？
最后，DDD中的模块与有界上下文有什么关系？
答案 0 :(得分：4)
在基础架构层（域外），这是一个技术细节。
有界上下文（BC）从域中出现，这就是我们识别它们而不是定义它们的原因。一旦确定，如果有许多BC并且有可用的开发人员，则可以拆分工作负载以便可以更快地开发应用程序。单个模型是不可取的，您需要每个BC的单个域模型以及用于查询的简化读取模型（CQRS）。
我不知道，但对我来说，Payroll是会计的一部分，实际上还没有2 BC。帐户是BC，但其他BC可能需要Payroll，但该定义特定于BC。可能定义只是一些数据（读取模型）。工资单行为应保留在会计中。因此，您需要通过“薪资”明确定义每个BC理解的内容。通常，您将拥有一个域名服务，他将使用两个BC的概念，并使用“翻译者”。
事实并非如此。模块只是从技术角度将事物分组在一起。 BC很虚拟，你可能会选择一个项目或模块对应一个BC，但这是你决定如何组织事物。
答案 1 :(得分：0)
- 如果一切都应该在有限的背景下，翻译者应该放在哪里？在埃文斯＆＃39;样本图，翻译是 外部（中间）两个有界的背景。
我认为这个问题毫无意义。每个BC是存在域模型的边界，并且边界由UL确定，每个BC具有其自己的UL。如果您只是创建一个模型，则不需要翻译。你没有将大型模型分成几个较小的模型，而是加入它们。
- 假设我们有一个团队致力于ERP。 ERP是应该放在几个有限的上下文中还是仅限于一个上下文中。基于埃文斯＆＃39; 样本，有界的背景被设计出来，以便多个团队可以 在他们自己的模型上工作。但由于这是一支单一的团队，所以不会 他们在单一模型上受益，因此整合不会成为一个问题？要么 我明白这个错了吗？
我认为你理解错了。您根据UL将单个模型拆分为多个BC，而不是可用的团队。然后，如果你没有足够的团队来创建BC，那么团队就必须开发不止一个BC。顺便说一句，相反的情况是不可取的，即BC不应该由不止一个团队开发。
- 在问题2的情况下，如果有多个有界上下文，如果在实现中，我们需要一个来自会计的类用于工资单？ 我不认为我们需要翻译，但我不确定如何分享 所需的课程。将仅引用所需的类 另一个有限的背景好吗？
您不应该引用另一个BC的域对象。 BC应保护其域模型，即应用层。应用程序层公开DTO，普通对象，它不应该将域模型暴露给外部世界。您要求的是共享内核（其他BC共享的模型）。
- 最后，DDD中的模块如何与有界上下文相关？
模块只是一个java包，可用于将彼此相关的内容保存在一起。所以你在模块中拆分BC的源代码。根据UL而不是技术方面来做。例如，每个聚合的模块，不是实体的模块，另一个是存储库的模块，等等。