上下文映射是一个工具，它允许您识别有界上下文之间的关系以及负责它们的团队之间的关系。

Image taken from https://www.oreilly.com/library/view/domain-driven-design-distilled/9780134434964/ch04.html

Vaughn Vernon的IDDD书中描述了几种集成多个有界上下文的方法:

• 伙伴关系
• 共享内核
• 客户的供应商
• 墨守成规
• 反腐败层
• 开放主机服务
• 发布的语言

根据代码的情况、团队的性质、业务本身、是否涉及第三方软件等，应该灵活地应用每一种方法。我将试着给出一个如何使用这些的例子。

伙伴关系

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

共享内核

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

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