看看上下文映射的清晰视图

在我之前的文章中，我详细讨论了有界上下文以及如何处理域的复杂性。最好将域划分为几个子域，并将它们映射到不同的有界上下文，其中每个业务实体/值对象在该上下文中都具有一定的含义，因此业务的每个利益相关者（产品所有者，开发人员，架构师和赞助商）都理解上下文和具有适当分类标准的实体。当我们在商业利益相关者之间以统一的语言讨论域对象时，就不会对命名造成混淆。

在有界上下文中，我们正确地定义了一个业务模型，根据业务领域创建了不同的上下文，但一个功能总是跨越多个业务实体，这些实体位于不同的有界上下文/域中，因此了解有界上下文之间的关系非常重要，架构业务解决方案上下文映射是一种技术，通过这种技术，我们可以可视化不同上下文之间的关系，集成架构师可以选择最佳的集成模式来与其他上下文进行通信。

为什么上下文映射在设计解决方案时如此重要

借助UML图，架构师可以了解不同部分与其他部分的通信方式。它为架构师提供了不同上下文之间通信的视图。这很好，但是上下文映射出现在UML图之前;这有助于可视化关系的本质，并且基于这种性质，架构师可以决定应该采用什么样的技术解决方案。

上下文映射可视化的最好部分是它讨论了关系的性质。它不仅告诉我们一段关系是上游还是下游，出版商还是订阅者，它还告诉我们不同的团队是如何依赖于其他团队，他们的主题，他们的政治…一切。考虑到所有这些，现在架构师可以在与另一个上下文集成的同时确定最佳解决方案，以最小化风险。

在微服务时代，上下文映射是关键的参与者，因为在设计之前，整体的微服务体系结构中，每个团队都拥有一个微服务，了解一个团队如何依赖其他团队是很重要的，哪个团队处于关键的位置，哪个团队寻求帮助;然后你就可以设计出最好的解决方案。

想想我们的学生在线家教应用。作为一个成熟的应用程序，它有超过50个微服务部署在生产中。在这里，有50个团队参与进来，为了开发一个功能——比如学生注册——多个上下文将会受到影响。我们可以说，要实现这个特性，将涉及多个团队，那么他们的关系是什么?在设计这个特性时，谁是最需要数据的pivot服务?显然，这项服务处于值得关键的地位。如果这个团队没有准备好，其他团队就不能做任何事情，所以所有的团队都应该与这个团队保持一致。他们必须与团队同步他们的产品积压，所以这里，内部政治进入画面。如果服务的数据来自于不在组织内部的外部团队，那么解决方案就更复杂了，因为您不能强迫它们，所以唯一的方法是请求它们并等待它们的更改。基于这些不同的场景，政治上下文映射有不同的解决方案。我将在这里介绍最重要的解决方案。

共享内核

共享内核讨论了两个或多个团队共享一个公共数据模型/值对象的伙伴关系。它减少了代码重复，因为不同的上下文使用相同的模型，但是相同的模型/值对象是非常敏感的，所以任何重大/次要的更改都应该得到所有各方的同意，否则它可能会破坏其他各方的代码，所以这些团队之间需要进行更多的通信和同步。假设一个团队需要一个通用模型的变更，但是另一个团队还没有准备好;前一个团队必须等待另一个伙伴准备好，或者另一方面，伙伴必须修改他们的代码，尽管这不是他们所需要的，但是必须要与其他伙伴同步。在保持伙伴关系的同时，各种各样的问题交织在一起，因此，当您的共同模型保持不变或偶尔更改时，请选择这种模式。

在我们的例子中，假设我们开发了一个分析模块，分析学生选择哪些课程，哪些学生选择了5门以上的课程等。该模块适用于学生领域模型和课程模型，因此我们的分析模块可以共享注册模块的学生模型，并随学生模型的变化同步变化。

客户/供应商

通常，这是两个上下文之间的公共关系，上下文使用或依赖于来自另一个上下文的数据。产生数据的上下文被标记为上游，而消耗数据的上下文被称为下游。当我们把这种关系想象成政治的时候，我们可以想象权力分配有很多阴影，就像下面这样:

作为领导者的上游

在这种关系中，上游团队处于一个关键的位置; 该团队不关心下游团队，因为他们生成数据，下游团队受上游团队的控制 - 他们总是根据上游团队生成的数据结构改变他们的模型。

在我们的学生注册应用程序中，支付应用程序和通知应用程序之间的关系属于上游和下游类型，支付应用程序决定提供哪些结构的信息以及通知模块使用该数据结构。

作为领导者的下游

在某些情况下，这种关系是相反的。尽管上游产生数据，但它必须遵循下游的规则/数据结构。在这种情况下，下游处于一个关键的位置。

假设在我们的Studen注册系统中，我们需要向政府提交表格16作为纳税人，因此我们的支付模块必须将表格16的数据提交给政府提供的API。但是，政府API具有提交表单数据的一定规则和数据结构，所以尽管政府API在下游，但它具有完全控制权。我们的支付模块应该以这种方式与下游进行沟通，以便能够满足下游的规则。

当上下游双方都配合工作时，客户-供应商关系最有效;双方已就该结构的接口和变更达成一致，如果合同发生变更，双方将进行讨论，以同步其优先级积压，并就变更达成一致。如果一方不关心另一方，那么每次合同被破坏，就很难维持客户-供应商的关系。

循规蹈矩

有时，两方之间存在一种关系，即下游团队总是依赖上游团队，他们不能与上游团队就需求达成一致。上游团队与下游团队不一致，不关心;他们可以随时更改发布的端点或契约，不接受来自下游的任何请求。当上游团队是一个外部系统或在不同的管理层次结构下，并且许多下游系统都注册了它，所以它不能优先考虑任何下游系统，而不是所有的下游系统都与上游联系和数据结构保持一致;如果上游契约或数据结构发生变化，那么下游的负责也随之变化。

比如，在我们的在线学生注册应用程序中，我们有一个免费的教程模块，所有学生或其他应用程序都可以使用我们的免费教程，并将它们嵌入到他们的应用程序中。在这里，我们的免费教程模块作为上游，独立于任何使用我们免费教程的第三方应用程序;我们不能优先考虑他们，而且我们与他们没有任何合同。如果我们更改了契约或数据结构，其他第三方有责任相应地更改他们的应用程序，以使用我们的免费教程。

反腐败层

当两个系统相互作用时，如果我们直接从上游消耗数据，由于上游数据结构通过下游泄漏，我们污染了我们的下游系统。如果上游受到污染，我们的下游也会这样做，因为它在消费时模仿上游数据。

在从第三方或传统应用程序中消费数据时，始终使用转换层（上游数据转换为下游数据结构，然后再转入下游数据结构）是一个好主意。这样，我们可以抵制来自上游的数据泄漏。如果上游合同发生变化，则不会污染下游内部系统; ;为了从上游采用新的数据结构并将其转换为下游数据结构，只需要修改转换层。这种技术被称为反腐败层。反腐败层将下游系统从上游更改中拯救出来。

在我们的应用程序中，通知模块可以在支付模块中使用数据时实施ACL（反腐蚀层），因此如果支付模块数据结构发生变化，则只有ACL层受到影响。

打开主机

在某些情况下，您的Domain API需要被许多其他服务访问，比如我们的Free Tutorial Publisher模块。许多外部或内部域需要使用此服务，因此作为上游服务，它应作为服务托管并维护协议和服务契约，如REST和JSON结构，以便其他系统可以使用这些数据。

发布语言

通常，两个或两个以上的系统彼此接收和发送消息。在这种情况下，需要使用通用语言将数据从一个系统转换为另一个系统，如XML和JSON。我们称该结构为已发布的语言。

我们的学生在线注册应用程序的鸟瞰图，根据上下文地图：

上下文映射是实现一个域如何与其他域通信的一个非常重要的练习。它提供了组织结构的正确视图、不同的域如何分布以及域所有者如何相互依赖。团队结构之间的关系是什么？它们可以与特征对齐吗？根据所有参数，一个集成工程师可以采用合适的集成模式来集成域吗？在设计集成解决方案之前，架构师总是必须定义一个上下文映射来理解团队的关系和结构，并在此基础上，架构师可以选择最佳解决方案。

原文作者：Shamik Mitra

原文地址：https://dzone.com/articles/ddd-thinking-in-terms-of-context-map