指限界上下文之间的模型映射关系。描述团队之间的协作关系及上下文之间的集成关系。决定上下文之间如何集成及如何设置防腐层。

　　我们要通过某种途径让订单上下文的一些信息发送到支付上下文。所以，要有一种描述方式，描述不同限界上下文之间交互的方式-上下文映射图（Context Map）。

　　知道不同限界上下文之间交互方式后，不同交互方式就可落地为不同协议。常用协议如：REST API、RPC 或是 MQ， 按需选型即可。

　　在我们定义好不同的限界上下文，将它们之间的交互呈现出来之后，就得到了一张上下文映射图。上下文映射图是可以帮助我们理解系统的各个部分之间，是怎样进行交互的，建立全局性认知。

　　日常开发很常见问题，由于限界上下文，当我们不同上下文之间需要交互时，如何将同一概念模型进行映射呢？就需要上下文映射。

　　服务提供方为所有消费方提供一套公共API，如各种云服务组件，直接提供API。云服务商不会为你单独定制 API，所以这种只针对通用功能和模型。如支付上下文，我们都会引入通用的微信公共支付API。

　　该协议是“开放的”，所有需要与限界上下文进行集成的客户端都能轻松使用它。通过API提供的服务都有详细文档，用着也舒服。

　　即使处在类似图中团队2的位置，也没有时间在这端的集成中创建隔离用的防腐层，和遗留系统相比，作为团队1模型的跟随者更容易被接受。开放主机服务的语言比其他类型的系统语言更易用。

　　存在于上游团队和下游团队间，上游团队无任何动机去满足下游团队具体需求。由于各种原因，下游团队也无法投入资源去翻译上游模型的通用语言来适应自己的特定需求日韩ip代理，因此只能顺应上游模型，即允许它（上游）对你（下游）的侵入。

　　当一个团队需要与一个庞大复杂的模型集成，且该模型已很成熟，团队往往会成为其跟随者。如在作为亚马逊联盟的卖家进行集成时，就需要考虑遵循的模型。

　　只剩下“部落知识”和“个人英雄主义”，唯有同时“讲”出所有语言的极个别“超人”方能扶大厦之将倾

　　问题是，大泥球已经遍布于世界上的软件系统中，这个数量还铁定会逐月增长。即使通过 DDD 避免创建自己的大泥球，仍可能不得不与它们集成。

　　若必须与一或多个这样的大泥球系统集成，请针对每个这样的遗留系统创建一个防腐层，保护自己模型免受污染，否则会陷入难以理解泥潭。

　　最具防御性的上下文映射关系，下游团队在其通用语言（模型）和位于它上游的通用语言（模型）之间创建个翻译层。防腐层隔离下游模型与上游模型，并完成二者间翻译。

　　但凡有可能，就该尝试在下游模型和上游集成模型之间创建防腐层， 才可以在你这端的集成中创造出特别适配业务需求的模型概念，并将外部概念完全隔离。

　　两个（或更多）团队之间，共享一个小规模但却通用的模型。团队必须就要共享的模型元素达成一致。有可能它们当中只有一个团队会维护、构建及测试共享模型的代码。

　　共享内核通常一开始很难理解，也难维护，因为团队之间沟通须完全开放，而且他们必须就共享模型的构成不断地达成一致。但只要所有参与者都认同共享内核比各行其道的方式更好，就有可能获得成功。

　　常见方式就是将通用模块通过二进制依赖（如 JAR 包或链接库）共享给所有上下文使用。持续地就修改进行开放式沟通并达成一致很困难，效率也很低，但蓬勃发展的开源软件社区却给我们做出表率。大部分开源软件都以二进制库的形式发布，开发者们也很难有直接面对面的沟通机会，但它们的发展和演进一点也不慢。开源软件开发者们会使用各种约定和相应实践进行沟通协作，使用 GitHub 的拉取请求（ Pull Request ）来审查代码并接受贡献或使用长期支持版本（ Long Term Support，LTS ）保持固定发布节奏给下游预留升级时间，又或是使用语义化版本（ Semantic Version ）向下游宣告破坏性修改。因此，越来越多的企业向开源社区学习，搭建基础设施和平台，建立企业的内部开源社区来开鼓励开发团队更高效地进行跨团队的协作。

　　两个上下文共享部分模型，包括但不限于代码、jar包、.so、数据库表等。慎用，仅当团队紧密合作且共享部分稳定。

　　关系存在于两个团队之间。每个团队各自负责一个限界上下文。两个团队通过互相依赖的一套目标联合起来形成合作关系。一损俱损，一荣俱荣。

　　由于相互之间联系紧密，他们经常会面对同步日程安排和相互关联工作 ，他们还必须使用持续集成对保持 成工作协调一致。两个团队之间的一致步调使用粗的映射线段表示。粗线段表示两个团队彼此需高度承诺。

　　保持长期的合作关系很有挑战性，因此许多进入合作关系的团队可能尽最大努力为这种关系设置一个期限。只有在能发挥彼此优势时才维持合作关系，而随承诺消失，这些优势不复存在，而这种合作关系应被重新映射成另外的一种关系。

　　支配这种关系的是供应商，因为它必须提供客户需要的东西。客户需要与供应商共同制订规划来满足各种预期，但最终却是由供应商决定客户获得的是什么及何时获得。即便是来自于同一个组织的团队，只要企业文化不允许供应商完全自治或无视客户的实际需求，客户一供应商关系也是一种非常典型且现实的关系。

　　和共享内核的映射关系一样，保持客户和供应商之间持续开放的沟通也很重要，持续沟通才能保障供应商按照客户的预期提供集成所需的接口。存在这种集成关系的团队常常会采用一种被称为消费者驱动契约（ Consumer Driven Contract, CDC ）的实践，通过契约测试来保证上游（生产者或供应商 和下游 （消费者或客户〉之间的协作。而利用 些工具（如 Pact ，客户可以在进行测试时，将对供应商接口的期记录下来，并将其变成供应商的接口测试，作为供应商持续 成流水线的一部分持续地进行验证。这样供应商可随时了解自己提供的接口实现是否满足客户期望。

　　和中台的协作关系是什么模式呢？中台应该是公司中姿态较低的，服务于业务方的，所以属于客户-供应商模式。中台的价值最终也只可能体现在业务上。由于中台需要服务多个业务方，自然就很可能成为大泥鳅，模型很难稳定下来，所以设计需要极强的经验。若中台能力实在太差，形同虚设，就可能出现如下模式：

　　意味着两个上下文之间根本没有关系，无需控制，也不需要承诺。在一个复杂的模型，存在着许多上下文，而大部分上下文之间应无直接依赖关系的。如账户子域（上下文）和物流子域（上下文）之间就没有直接联系。如果任何两个上下文之间都有直接联系，整个模型就要走向大泥球。两个上下文之间没有任何依赖，自由地独立演进，这应该是我们最希望的。因此，在可能情况下，我们应该把两个上下文分开，让它们各行其道。

　　使用各种通用语言来与一个或多个限界上下文集成这样的方式不能产生显著回报。也许你所寻求的功能并不能由任何一种通用语言提供。此时，只能在限界上下文中创造属于自己的特殊解决方案，并放弃针对这种特殊情况的集成。