Anti-corruption Layer pattern
(https://learn.microsoft.com/en-us/azure/architecture/patterns/anti-corruption-layer)
简单描述
- 实现一个门面或者适配层在新应用和历史遗留程序之间。
- 在不同的系统之间实现一个门面或者适配层，不需要使用相同的语义。它在不同的子系统之间转换了请求。使用这种设计模式可确保一个应用程序设计不受外部系统依赖的限制。这个设计模式由Eric Evans在Domain-Driven Design中首次提出。
背景和问题
-
大部分应用的一些功能依赖于其他系统。例如，当一个历史遗留应用迁移到新系统中，可能依然需要一些历史遗留资源。新特性必须能够去调用历史遗留系统。对于逐渐迁移来说尤其如此，随着时间的推移 ，大型应用程序的不同特性都会移到新系统中。
- 很多情况下历史遗留系统会受到质量问题的影响，例如复杂的数据结构或者过时的API。遗留历史系统的特性和技术与大部分新应用大相径庭。对于遗留系统的交互操作，新应用需要支持过时的基础组件，协议，数据模型，API等其他不需要添加到新应用里的特性。
- 维护新系统和遗留系统之间的访问可以迫使新系统至少遵守一些遗留系统的api或其他语义。当这些遗留特性存在质量问题时，支持它们会“破坏”原本设计干净的新应用。
- 类似问题可能发生在任何一个你的开发团队不能控制的外部系统，不仅仅是遗留系统。
解决办法
- 通过在不同的子系统之间放置防腐层来隔离他们。防腐层转换两个系统之间的通信，允许一个系统保持不变，而其他系统可以避免妥协其设计和技术方式。
上面这个图展示了一个应用的两个子系统。子系统A通过防腐层调用子系统B。子系统A和防腐层的通信始终使用子系统A的数据结构和设计。防腐层调用并遵守子系统B的数据结构或者方法。防腐层包含了在两个系统之间转换需要的逻辑。它可以独立为一个组件或者是独立的服务。
问题和考虑
- 防腐层可能会增加两个系统之间的调用延迟
- 防腐层增加了额外需要维护和管理的服务
- 考虑防腐层如何扩展
- 考虑你是否需要多个防腐层。你可能想要拆分功能到使用不同技术或者语言的服务中，或者划分防腐层可能还有其他原因
- 考虑如何管理与你的应用程序或者服务有关的防腐层。如何集成到你的监控、发布和配置过程中
- 确保事务和数据的一致性得到维护，并且可以被监控考虑防腐层是否需要处理所有的不同子系统之间的通讯，或者只是一小部分的特性
- 如果防腐层是一个应用迁移策略的一部分，考虑是否永久保留它，或者等迁移结束后废弃它
- 上面用不同的子系统说明了此模式，但是也可以应用在其他服务架构，例如当迁移遗留代码到一个单体架构中
什么时候使用
- 迁移计划在多个阶段进行，但是需要维护新老系统的集成
- 两个或者多个子系统使用不同语义，但是需要互相通讯
不适合的场景
- 新老系统之间没有很显著的语义差异
欢迎大家留言沟通
