反腐层模式

在语义不一致的不同子系统之间引入外观层或适配器层。 此层转换一个子系统向另一个子系统发出的请求。 使用此模式可确保对外部子系统的依赖关系不会限制应用程序的设计。 Eric Evans 最早在《领域驱动设计：软件核心复杂性应对之道》一书中描述了这种模式。

上下文和问题

大多数应用程序依赖于其他系统来获取某些数据或功能。 例如，将旧版应用程序迁移到新式系统时，应用程序可能会继续使用现有的旧版资源。 新功能必须能够调用旧系统。 此功能对于逐步迁移尤其重要，因为随着时间推移，将较大应用程序的不同功能移动到新式系统。

这些旧系统通常存在诸如卷积数据架构或过时 API 等质量问题。 旧版系统使用的特性和技术可能因更现代的系统而异。 若要与旧系统进行互作，新应用程序可能需要支持过时的基础结构、协议、数据模型、API 或其他功能，否则不会放入新式应用程序。

在新的和旧系统之间保持访问权限时，强制新系统遵守至少一些旧系统的 API 或其他语义。 当这些旧功能存在质量问题时，此支持会损坏其他可能设计简洁的新式应用程序。

开发团队无法控制的任何外部系统都可能出现类似的问题。

解决方案

通过在这些子系统之间放置防腐层来隔离不同的子系统。 此层转换两个系统的通信。 通过使用此方法，可以保持一个系统不变，而不会损害另一个系统的设计和技术方法。

下载此体系结构的 Visio 文件。

此图显示了具有两个子系统的应用程序。 子系统 A 通过防腐层调用子系统 B。 子系统 A 和反腐层之间的通信始终使用子系统 A 的数据模型和体系结构。从反损坏层调用子系统 B 符合该子系统的数据模型或方法。 反腐层包含两个系统之间转换所需的所有逻辑。 可以将层作为应用程序内的组件或独立服务实现。

问题和注意事项

在决定如何实现此模式时，请考虑以下几点：

• 反腐层增加了两个系统之间的调用延迟。

• 反腐层增加了一项额外的服务，必须对其进行管理和维护。

• 考虑你计划如何扩展防腐层。

• 考虑是否需要多个防腐层。 例如，你可能希望将功能分解为使用不同技术或语言的多个服务。

• 考虑如何规划管理与其他应用程序或服务相关的防腐层，以及如何将其集成到监视、发布和配置过程中。

• 确保维护和监视事务和数据一致性。

• 考虑反腐层是否需要处理不同子系统之间的所有通信，还是只处理一部分功能。

• 如果防腐层是应用程序迁移策略的一部分，请考虑它是永久性的，还是计划在迁移所有旧功能后停用它。

• 上图使用不同的子系统来说明此模式，但也可以将其应用于其他服务体系结构，例如整体体系结构中的旧代码集成。

• 由于反腐层调解可能具有不同信任级别的系统，因此请考虑在此边界强制实施输入验证和清理。

• 规划可观测性，包括相关 ID 和结构化日志记录，以诊断翻译失败。

何时使用此模式

在以下情况下使用此模式：

• 你计划在多个阶段进行迁移，但需要保持新系统与旧系统之间的集成。

• 两个或多个子系统具有不同的语义，但需要通信。

在以下情况下，此模式可能不适用：

• 新的和旧的系统没有明显的语义差异。 在这种情况下，重要的是将反腐败层的重点放在转换逻辑上。 避免在该层中放置业务规则或编排。

工作负载设计

评估如何在工作负载设计中使用反腐层模式，以实现Azure Well-Architected Framework 支柱中涵盖的目标和原则。 下表提供有关此模式如何支持每个支柱目标的指南。

如果此模式在某个支柱中引入权衡取舍，请将它们与其他支柱的目标进行对比。

Example

此模式是概念性的，源于域驱动的设计软件开发方法。 Azure Azure API 管理或Azure Functions等服务可能有助于处理和转换协议，但反腐败层的核心目的是保护域模型，而不是规定任何特定的产品选择。

在以下示例中，API 管理处理外部公开和协议问题。 Azure Functions通过新系统与旧系统之间的域映射来实现反腐层。 Azure Monitor 和 Application Insights 提供了所需的可观测性，用于跟踪两个子系统之间转换过程的成功率和延迟。

除了此同步请求响应模型之外，反腐层还可以使用异步的事件驱动方法。 通过使用Azure 服务总线、Azure 事件网格或Azure 事件中心，层将新式域与旧系统的吞吐量约束分离，以允许基于消息的高吞吐量或高度分离工作负荷的转换。

后续步骤

• 探索有助于管理分布式事务和维护数据一致性（例如 补偿事务模式 和 Saga 分布式事务模式）的云设计模式。

• 由于防腐层可能成为单点故障，因此应通过使用 重试模式、断路器模式、舱壁模式 和 运行状况终结点监控模式来规划系统韧性。

相关资源

• Strangler Fig 模式
• 消息传送桥模式