伙伴关系

它更多地描述了团队之间的关系，而不是实际的代码。这种情况通常发生在两个团队在两个有界的环境中工作，并且有一致和相关的目标集的时候。每个团队至少应该理解他们的合作伙伴的一些无处不在的语言，即对他们自己的上下文感兴趣的东西。当两个有界上下文都处于项目的早期阶段时，这种方法可以很好地工作，因为在早期阶段，通信比实现其他一些技术更快、更有效。当双方变得更加稳定时，团队可能会因为理解彼此的通用语言而承担太多的义务。当然，如果一个团队要在这两个有限的上下文中工作，那么“伙伴关系”的成本就会低得多。

共享内核

2个或多个有界上下文可以共享一个公共模型。在设计术语中，这个共享部分的通用语言对于所有相关的团队都是通用的。在代码术语中，您可能有一个共享库或服务。这通常是一个小的代码库，但是随着相关的有界上下文的发展而难以维护，因为随着团队自身的有界上下文的发展，团队将倾向于采用不同的方式。

消费者/供应者

此方法将两个有界上下文放入上游和下游，其中上游是供应商，并且必须尝试满足客户(下游)的期望。但是最终决定客户得到什么的是供应商。这通常在同一组织内的自治环境中工作，或者如果客户是供应商的唯一客户。

墨守成规

此关系描述了两个有界上下文的关系，其中上游出于某种原因没有兴趣支持下游。相反，下游必须遵循上游所提供的内容。当将一个新特性与一个已经建立的大型现有解决方案集成时，可能会出现这种情况;或者使用一组api，而下游不是唯一的客户。

反腐败层(ACL)

这是较低级别上的另一个上游/下游关系，其中下游有界上下文实现了自身与上游之间的一个层。这一层负责将上游给出的对象转换成它自己的模型。这种方法将保证下游有界上下文的完整性，并使其完全不受任何外来概念的影响。此方法通常用于将新功能集成到某些现有遗留软件中，在这些软件中，可以将现有遗留软件视为黑盒边界上下文，并为新功能创建ACL。

开放主机服务(OHS) /发布的语言(PL)

我将同时讨论这两种方法，因为它们都定义了一种关系，在这种关系中，上游提供了一组关于集成模型的良好记录或随时可用的信息。这是建立在早期的墨守成规的方法之上的，在早期，下游要容易得多。上游还需要提供版本支持。通常，上游有界上下文将支持多个客户机，并且对特别支持某个客户机不感兴趣。例如，为了符合Amazon api，下游将通过理解Amazon提供的文档对集成有信心。

总之，理解各种上下文映射技术可以更有效地集成有界上下文。同样重要的是，首先要考虑集成是否必要并为业务带来好处。同时使用多种方法也是可以接受的，有时是首选的。例如，拥有RESTful API自然会提供OHS，但同时，下游也可能被鼓励实现自己的ACL，特别是当上游服务由第三方提供时。您的团队将是根据当前情况决定使用哪种方法的最佳人员。

原文：https://medium.com/ingeniouslysimple/context-mapping-in-domain-driven-design-9063465d2eb8

本文：https://pub.intelligentx.net/ddd-context-mapping-domain-driven-design

讨论：请加入知识星球【首席架构师圈】或者飞聊小组【首席架构师智库】