防损层模式
在不同不共享相同语义的不同子系统之间实现外观层或适配器层。 此层转换一个子系统向另一个子系统发出的请求。 使用此模式可确保应用程序的设计不受外部子系统上的依赖项的限制。 此模式首先由埃里克·埃文斯在 Domain-Driven 设计中描述。
上下文和问题
大多数应用程序依赖于其他系统来获取某些数据或功能。 例如，将旧版应用程序迁移到新式系统时，它仍可能需要现有的旧版资源。 新功能必须能够调用旧系统。 对于逐步迁移尤其如此，随着时间推移，大型应用程序的不同功能将移动到新式系统。
通常，这些旧系统存在质量问题，例如卷积数据架构或过时的 API。 旧系统中使用的特性和技术可能与更现代的系统不同。 若要与旧系统进行互作，新应用程序可能需要支持过时的基础结构、协议、数据模型、API 或其他你不会放入新式应用程序的功能。
维护新系统与旧系统之间的访问可以强制新系统遵守至少一些旧系统的 API 或其他语义。 当这些旧功能存在质量问题时，支持它们“损坏”，否则可能是设计干净的新式应用程序。
开发团队无法控制的任何外部系统都可能出现类似的问题，而不仅仅是旧系统。
解决方案
通过在这些子系统之间放置防腐层来隔离不同的子系统。 此层转换两个系统之间的通信，允许一个系统保持不变，而另一个系统可以避免损害其设计和技术方法。
上图显示了具有两个子系统的应用程序。 子系统 A 通过防腐层调用子系统 B。 子系统 A 和反腐层之间的通信始终使用子系统 A 的数据模型和体系结构。从反损坏层调用子系统 B 符合该子系统的数据模型或方法。 反腐层包含两个系统之间转换所需的所有逻辑。 层可以作为应用程序内的组件或独立服务实现。
问题和注意事项
- 反腐层可能会给两个系统之间的调用增加延迟。
- 反腐层增加了一个必须管理和维护的其他服务。
- 考虑反腐层的缩放方式。
- 考虑是否需要多个防腐层。 你可能希望使用不同的技术或语言将功能分解为多个服务，或者可能出于其他原因来对反损坏层进行分区。
- 考虑如何管理与其他应用程序或服务相关的防腐层。 它将如何集成到监视、发布和配置流程中？
- 确保维护事务和数据一致性，并可以监视。
- 考虑反腐层是否需要处理不同子系统之间的所有通信，还是只处理一部分功能。
- 如果反腐层是应用程序迁移策略的一部分，请考虑它是永久性的，还是将在迁移所有旧功能后停用。
- 上述不同子系统演示了此模式，但也适用于其他服务体系结构，例如，在整体体系结构中集成旧代码时。
何时使用此模式
在以下情况下使用此模式：
- 迁移计划跨多个阶段进行，但需要维护新系统与旧系统之间的集成。
- 两个或多个子系统具有不同的语义，但仍需要通信。
如果新系统与旧系统之间没有明显的语义差异，则此模式可能不适用。
工作负荷设计
架构师应评估如何在工作负荷的设计中使用反腐层模式来解决 Azure Well-Architected 框架支柱中涵盖的目标和原则。 例如：
| 支柱 | 此模式如何支持支柱目标 |
|---|---|
| 卓越运营 通过 标准化流程 和团队凝聚力，帮助交付 工作负载质量。 | 此模式有助于确保在与这些旧系统集成时，新组件设计不受传统实现的影响，这些实现可能具有不同数据模型或业务规则，并且它可以减少新组件中的技术债务，同时仍支持现有组件。 - OE：04 工具和流程 |
与任何设计决策一样，请考虑对可能采用此模式引入的其他支柱的目标进行权衡。