领域驱动设计实践 - 第四天：理解上下文映射的重要性与应用

今天我们开始聊聊上下文图。

项目的限界上下文可以用两种方式来表达。一种更简单的方式是画一个简单的图来展示两个或多个现有限界上下文（2）之间的映射关系。不过，你要明白，你画的只是现有系统之间关系的简单示意图。这张图展示了实际的软件限界上下文是如何通过整合在解决方案的范围中相互关联的。

为什么说上下文地图（Context Maps）很重要？

在你将界定上下文集成到大型企业中时，你可能需要与一个大泥球进行接口。维护泥球单体的团队可能并不关心你的项目的方向，只要你们遵守他们的API，他们不会从你的领域图中获得任何有用信息，也不会关心你如何使用他们的API。然而，你的领域图仍然需要反映出你与他们的关系，因为它将为你的团队提供所需的信息，并指出沟通至关重要的领域。这有助于你的团队取得成功。

如图所示，这是一张...的照片。

• ❓ 要注意一下

如果这样会发生什么，如果你们团队假设维护泥状系统的团队会提供你们所依赖的新 API，但对方根本没有打算提供这些 API，或者甚至完全不知道你们的想法。你们团队指望与泥状系统建立客户-供应商关系，然而遗留团队只提供他们当前拥有的内容，迫使你们团队陷入了意想不到的从属关系。根据你们在项目中何时得知这个坏消息，这种关系可能会延迟你们的交付，甚至导致项目失败。尽早绘制上下文图可以迫使你们仔细审视和所有项目的关系。

• ❌ 不正确的想法

上下文图并不是企业架构图或系统拓扑图。它传达的信息是基于交互模型和领域驱动设计中的模式。

• 合作伙伴关系：当两个团队在两个上下文中会共同进退时，需要形成一种合作关系。团队需要设立一个协调开发计划的过程，并共同管理集成。团队必须在接口演进上进行合作，以适应两个系统各自的发展需求。相互依赖的功能应安排在同一版本中完成。

• 共享内核：共享部分模型和相关代码形成了非常紧密的相互依赖关系，这可能会利用设计工作或破坏它。定义一个明确的共享范围，该范围是一组团队同意共享的领域模型的一部分。保持内核精简。这个共享内容具有特殊地位，未经其他团队同意不得更改。定义持续集成流程，以保持内核模型的紧密性，并统一团队的通用语言(1)。

• 客户供应商共同发展：当两个团队处于上下游关系时，上游团队的成功可能并不依赖于下游团队的命运，下游团队的需求将以多种方式得到解决，产生各种不同的影响。下游优先事项会考虑进上游的计划中。协商和预算下游需求的任务，以确保每个人都清楚承诺和时间表。

• 顺行者：当两个开发团队存在上下游关系，而下游团队因为上游团队缺乏满足他们需求的动力而感到无能为力时，利他主义可能促使上游开发者做出承诺，但这些承诺往往难以兑现。下游团队通过完全遵循上游团队的模式，避免了跨越有界上下文时的翻译复杂性。

• 防御层：当翻译层连接设计良好的限界上下文和合作团队时，它可以很简单，甚至很优雅。但是，如果控制或沟通不足以支撑共享内核、合作伙伴或客户供应商关系时，翻译就会变得更复杂。翻译层会变得更加防御性。作为下游客户端，你需要创建一个隔离层，以你自己的领域模型为基础，为你的系统提供上游系统的功能。该层通过现有的接口与另一个系统通信，几乎不需要修改另一个系统。内部，该层根据需要在两个模型之间进行单向或双向的翻译。

• 开启主机服务功能：定义一个协议，使你的子系统能够作为一个服务集提供访问。开放此协议，让所有需要与你集成的人都能使用它。扩展协议以适应新的集成需求，除非某个团队有独特需求。对于这种情况，使用一个一次性转换器来增强协议，以便保持共享协议的简单和一致性。

• 发布语言：两个有界上下文模型之间的翻译需要一种共同语言。使用一种经过良好记录的共享语言作为沟通媒介语言，该语言能有效表达所需业务信息，并在必要时进行翻译。发布语言通常与开放主机服务配合使用。

• 分道扬镳：在定义需求时我们应该坚决果断。如果两组功能之间没有显著关联，就应该将它们彻底分开。集成总是代价高昂，有时收益甚微。界定一个限界上下文与其他上下文完全无关，让开发人员在这个小范围内找到简单且专业的解决方案。

• 大一团乱麻：当我们查看现有的系统时，我们发现实际上系统中存在一些部分，往往是较大的部分，其中模型混乱，边界模糊。将整个混乱的部分圈起来叫“大一团乱麻”。不要试图在这里搞复杂的模型。要注意这些系统倾向于蔓延到其他地方。

下次咱们聊一聊建筑吧 🥰