领域驱动设计：防腐层（ACL），让你的程序没有羁绊

技术本质

Eric Evans：When systems based on different models are combined, the need for the new system to adapt to the semantics of the other system can lead to a corruption of the new system’s own. The underlying concept is pretty clear. When we need to "talk" with other system, data repository or legacy code (even "ours" legacy code) we should prevent our model from other "foreign models".（网页翻译：当基于不同模型的系统组合在一起时，新系统需要适应其他系统的语义，这可能导致新系统本身的腐败。 基本概念非常清楚。当我们需要与其他系统、数据存储库或旧代码（甚至"我们的"旧代码）进行"对话"时，我们应该阻止我们的模型与其他"外部模型"进行对话。）

DDD 定义的反腐败层，包含3个组件：适配、转换、外观，将系统中的一部分（DDD 称为边界上下文）与另一个边界上下文隔离开来。它的工作是确保一个边界概念中的语义不会"腐蚀"另一个边界概念的语义。

需求背景

假设现在要做一个支付 API 与其他系统、信用卡、借记卡等进行通信，这些子系统中的每一个都有不同的模型，我不希望主系统过度依赖这些子系统。

解决方案

创建防腐层，分别解决以下问题：

• 引入转换器模式，将多个支付模型都转换为标准 API 模型
• 引入外观模式，将多个接口进行封装，对调用层提供更精简的接口，让调用者更加容易地间接使用外部系统功能
• 引入适配者模式，将外部系统提供的不兼容的接口，转换为适合调用者的接口

职责

• 异常降级：对RPC调用可能抛出的异常捕获，降级处理（输出异常日志、返回empty结果 / 抛出业务异常errorcode）；
• 超时/重试：对RPC接口的超时、重试进行统一管理
• 数据校验：对返回值的正确性、边界值进行校验，进行数据的基本防御、业务代码边界值的解耦；
• 接口防腐：转换成Vo值对象（展示用的数据），避免下游接口的修改导致自身系统的修改

引入的问题

• 防腐层可以作为内部组件适用，也可以作为一个服务独立部署；独立部署可能增加了系统通信延迟，增加性能损耗，而且需要考虑高可用
• 哪些内容可以放到防腐层中，开发的的边界如何界定
• 写更多的代码，增加相应的维护成本

实践示例（待补充）