一些总结：
-
防腐层 - 在拥有不同语义的子系统之间实现一个门面（façade）或者适配（adapter）层来翻译一个子系统到另一个的请求。可以让两个子系统不必因为依赖关系而影响其设计。最早是由 Eric Evans 在领域驱动设计中提出。
-
主要的应用场景在于遗留系统的升级改造以及外部第三方系统的对接。改造以及对接的本质是依赖了无法控制的服务和系统，要避免它们对当前系统的设计产生影响。
-
使用防腐层模式需要考虑的点：
-
会增加调用延迟；增加了需要维护的额外服务
-
需要考虑防腐层如何 scale；考虑防腐层是否需要以及如何拆分功能
-
保证事务和数据一致性不受影响
-
考虑防腐层的生命周期，是仅存在于迁移过程中还是一直存在
-
Anti-corruption Layer pattern
Implement a façade or adapter layer between different subsystems that don't share the same semantics. This layer translates requests that one subsystem makes to the other subsystem. Use this pattern to ensure that an application's design is not limited by dependencies on outside subsystems. This pattern was first described by Eric Evans in *Domain-Driven Design *.
Context and problem
Most applications rely on other systems for some data or functionality. For example, when a legacy application is migrated to a modern system, it may still need existing legacy resources. New features must be able to call the legacy system. This is especially true of gradual migrations, where different features of a larger application are moved to a modern system over time.
Often these legacy systems suffer from quality issues such as convoluted data schemas or obsolete APIs. The features and technologies used in legacy systems can vary widely from more modern systems. To interoperate with the legacy system, the new application may need to support outdated infrastructure, protocols, data models, APIs, or other features that you wouldn't otherwise put into a modern application.
Maintaining access between new and legacy systems can force the new system to adhere to at least some of the legacy system's APIs or other semantics. When these legacy features have quality issues, supporting them "corrupts" what might otherwise be a cleanly designed modern application.
Similar issues can arise with any external system that your development team doesn't control, not just legacy systems.
Solution
Isolate the different subsystems by placing an anti-corruption layer between them. This layer translates communications between the two systems, allowing one system to remain unchanged while the other can avoid compromising its design and technological approach.
The diagram above shows an application with two subsystems. Subsystem A calls to subsystem B through an anti-corruption layer. Communication between subsystem A and the anti-corruption layer always uses the data model and architecture of subsystem A. Calls from the anti-corruption layer to subsystem B conform to that subsystem's data model or methods. The anti-corruption layer contains all of the logic necessary to translate between the two systems. The layer can be implemented as a component within the application or as an independent service.
Issues and considerations
-
The anti-corruption layer may add latency to calls made between the two systems.
-
The anti-corruption layer adds an additional service that must be managed and maintained.
-
Consider how your anti-corruption layer will scale.
-
Consider whether you need more than one anti-corruption layer. You may want to decompose functionality into multiple services using different technologies or languages, or there may be other reasons to partition the anti-corruption layer.
-
Consider how the anti-corruption layer will be managed in relation with your other applications or services. How will it be integrated into your monitoring, release, and configuration processes?
-
Make sure transaction and data consistency are maintained and can be monitored.
-
Consider whether the anti-corruption layer needs to handle all communication between different subsystems, or just a subset of features.
-
If the anti-corruption layer is part of an application migration strategy, consider whether it will be permanent, or will be retired after all legacy functionality has been migrated.
When to use this pattern
Use this pattern when:
-
A migration is planned to happen over multiple stages, but integration between new and legacy systems needs to be maintained.
-
Two or more subsystems have different semantics, but still need to communicate.
This pattern may not be suitable if there are no significant semantic differences between new and legacy systems.
