学习领域驱动设计

第 9 章 沟通模式 交流模式

本作品已使用人工智能进行翻译。欢迎您提供反馈和意见：[e-mail]

第5-8章介绍了战术设计模式，这些模式定义了实现系统组件的不同方法：如何为业务逻辑建模，以及如何从架构上组织有界上下文的内部结构。在本章中，我们将超越单个组件的界限，讨论组织系统元素间通信流的模式。

本章将介绍的模式可促进跨边界上下文通信，解决聚合设计原则带来的限制，并协调跨越多个系统组件的业务流程。

模型翻译

有界上下文是模型--一种无处不在的语言--的边界。 正如你在第 3 章中所学到的，在不同的边界上下文中设计通信有不同的模式。假设实施两个有界上下文的团队进行了有效的沟通并愿意合作。在这种情况下，就可以通过合作的方式整合这些有界上下文：协议可以临时的方式进行协调，任何整合问题都可以通过团队之间的沟通得到有效解决。另一种合作驱动的集成方法是 共享内核：团队提取并共同演化模型的有限部分；例如，将边界上下文的集成合约提取到一个共同拥有的存储库中。

在客户与供应商的关系中，权力的天平要么倾向于上游（供应商），要么倾向于下游（消费者）。假设下游受约束情境无法符合上游受约束情境的模式。在这种情况下，就需要一种更复杂的技术解决方案，通过转换有界语境的模型来促进沟通。

这种转换可以由一方处理，有时也可以由双方处理：下游有界上下文可以使用反破坏层（ACL）使上游有界上下文的模式适应自身需要，而上游有界上下文可以作为开放主机服务（OHS），通过使用特定于集成的发布语言保护其消费者免受其实现模式变化的影响。由于反中断层和开放式主机服务的翻译逻辑相似，本章在介绍实现方案时不区分这两种模式，仅在特殊情况下提及两者的区别。

该模型的翻译逻辑可以是无状态的，也可以是有状态的。 无状态翻译是在发出传入（OHS）或传出（ACL）请求时即时进行的，而有状态翻译则涉及需要数据库的更复杂的翻译逻辑。让我们来看看实现这两种类型模型翻译的设计模式。

无状态模型转换

对于无状态模型转换，拥有该转换的有界上下文（上游为 OHS，下游为 ACL）会实施代理设计模式，以插入传入和传出请求，并将源模型映射到有界上下文的目标模型。如图 9-1 所示。

图 9-1. 通过代理进行模型翻译

代理的实现取决于受限上下文是同步通信还是异步通信。

同步

翻译同步通信 中使用的模型的典型方法是将转换逻辑嵌入绑定上下文的代码库中，如图 9-2 所示。在开放主机服务中，处理传入请求时会将模型翻译成公共语言；在反中断层中，调用上游绑定上下文时会将模型翻译成公共语言。

图 9-2. 同步通信

在某些情况下，将翻译逻辑卸载到外部组件（如 API 网关模式）可能更具成本效益，也更方便。API 网关组件可以是基于开源软件的解决方案，如 Kong 或 KrakenD，也可以是云供应商的托管服务，如 AWS API Gateway、Google Apigee 或 Azure API Management。

对于实施开放主机模式的有界上下文，API 网关负责将内部模型转换为集成优化的发布语言。此外， ...