DDD的简单落地及防腐层（ACL）

服务器后端发展三个阶段：

1. 面向过程脚本：初始简单，业务复杂后，维护难度指数上升。--> 基本不使用
2. 面向数据库表：初始难度中，业务复杂后，维护难度延迟后再指数上升。--> 目前市面主流
3. 面向业务模型：以领域模型替代替数据库表模型（ DDD+SOA微服务：事件驱动的CQRS读写分离架构）

DDD内核

领域驱动设计是一种由领域模型来驱动系统设计的思想，不是通过数据库表来驱动系统设计。

领域模型是对业务模型的抽象，DDD革命性在于：领域模型准确反映了业务语言，传统数据对象除了简单setter/getter方法外，没有任何业务方法，即失血模型，而DDD领域采用充血模型（业务方法定义在实体对象中，例如：生成订单时，判断商品不能为空）。

模型（Model）承载着业务的属性和具体的行为，是DDD的内核。充血模型不仅有属性、Get/Set方法，并且包含业务的行为（Action）操作。模型分为Entity、Value Object、Service这三种类型。

1. Entity (实体)
   1. 有特定的标识，标识着这个Model在系统中全局唯一
   2. 内部值可以是变化的，可能存在生命周期 (比如订单对象，状态值是连续变化的)
   3. 有状态的Value Object
2. Value Object （值对象）
   1. 内部值是不变的，不存在生命周期 (比如地址对象)
   2. 无状态对象
3. Service （服务）
   1. 无状态对象
   2. 当一个属性或行为放在Entity、Value Object中模棱两可或不合适的时候就需要以Service的形式来呈现

在领域建模时：模棱两可，优先选择简单模型原则。

DDD分层架构

Evans在它的《领域驱动设计》书中推荐采用分层架构去实现领域驱动设计，典型的4层架构：

 注：简单查询不涉及业务，是可以直接从应用层穿透到基础层。DDD本身不限制非业务类操作跨层调用。

代码模型

对应DDD4层架构设计，建立 interfaces、application、domain 和 infrastructure 目录。

用户接口层

api：提供面向外部的接口声明和DTO对象

controller：提供HTTP访问入口和参数校验

应用层

service：业务层，对多个领域服务或外部服务进行编排、组合。

facade：将用户请求委托给一个或多个应用服务进行处理。

event（事件）：包括两个子目录 publish 和 subscribe。主要存放事件发布、订阅的相关代码（事件处理的核心业务逻辑在领域层实现）

领域层

service：领域服务

entity：提供DMO（DomainObject），实体类提供转DO方法。

repository（仓储服务）：做类型转换（entity to DO）并调用dao层。

基础层

config：配置

common：公共组件

dao：DB操作

---

防腐层（Anti-corruption layer）

防腐层（Anti-Corruption Layer）模式，是一种在不同语义的子系统间构建的一层功能，对子系统间的请求进行翻译适配，从而确保应用设计不受外部依赖的系统的限制。

应用场景

许多应用依赖于外部系统提供的数据或者功能。当直接使用外部系统的API、数据结构时，自身就存在因使用外部系统，而被外部系统的质量问题影响，从而“腐化”本身设计的问题。比如，当一个遗留应用需要移植到新系统时，可能仍需使用现存的遗留资源，新的特性需要调用遗留系统。这种场景在系统迁移过程中尤其普遍。

解决方案

在应用自身与外部之间，构筑专门的一层组件或者服务，对两个系统进行通讯转换和语义隔离。这层组件或者服务，称为“防腐层”。

 如上图所示的引入了防腐层的架构中：

• 子系统A与防腐层之间的通讯，使用子系统A的数据模型和架构；

• 子系统B与防腐层之间的通讯，则使用子系统B的数据模型和架构；

• 防腐层实现了在两个系统之间进行通讯转换的全部逻辑（双向转换）。

问题

• 防腐层可能增加两个系统间的通讯延迟；

• 防腐层增加了额外的服务，需要管理和维护；

• 如果防腐层是系统迁移战略的一部分，则需要考虑防腐层是否是永久的，是否在遗留系统功能完全迁移完成后将其移除。

---

DDD除了分层架构的实现之外，还有其他更深层次的架构方案：

领域驱动设计落地【转】 - 小天儿 - 博客园 (cnblogs.com)https://www.cnblogs.com/ningskyer/articles/11582090.html