DDD(Domain-Driven Design)领域驱动设计

出现背景

三层应用架构：数据 - 应用 (业务逻辑层)- 展现，通常是以数据位为起点进行数据库分析设计,服务层过重，数据模型失血，没东西.

1. 面条式编程或者面向数据库编程，服务层围绕数据库作业完成业务逻辑，经常一条线撸到底；

2. 代码一整块一整块的过重，很难扩展复用；

3. 数据库模型只是数据库映射，没有相关的行为支撑，行为都被上一层 Service 给完成等了，因此是失血的领域模型；

领域模型是对业务模型的抽象，DDD革命性在于：

领域模型准确反映了业务语言，传统数据对象除了简单setter/getter方法外，没有任何业务方法，即失血模型

而DDD领域采用充血模型（业务方法定义在实体对象中，例如：生成订单时，判断商品不能为空）

分层

• 接口层
  • 对外提供能力/接口，HTTP接口，RPC接口等
• 应用层
  • 接口与核心之间的层次，主要是将核心对象封装、组合成完整的业务流程，为接口提供服务
• 领域层/核心层
  • 将核心业务逻辑拆分为功能相对独立的各个子模块。 子模块和具体业务流程无关或关联性不大，封装了核心的知识，并对外提供抽象接口。
• 基础设施层/防腐层/ACL
  • 服务对外依赖，包括数据库、消息队列等

三层架构到四层架构之间的演进

图源-DDD分层架构浅析-架构狂人

• 三层架构向DDD分层架构演进，主要发生在业务逻辑层和数据访问层。

  • DDD分层架构在用户接口层引入了DTO，给前端提供了更多的可使用数据和更高的展示灵活性。

  • DDD分层架构对三层架构的业务逻辑层进行了更清晰的划分，改善了三层架构核心业务逻辑混乱，代码改动相互影响大的情况。

  • DDD分层架构将业务逻辑层的服务拆分到了应用层和领域层。应用层快速响应前端的变化，领域层实现领域模型的能力。

• 另一个重要的变化发生在数据访问层和基础层之间。

  三层架构数据访问采用DAO方式；

  DDD分层架构的数据库等基础资源访问，采用了仓储（Repository）设计模式，通过依赖倒置实现各层对基础资源的解耦。

  仓储又分为两部分：仓储接口和仓储实现。

  仓储接口放在领域层中，仓储实现放在基础层。原来三层架构通用的第三方工具包、驱动、Common、Utility、Config等通用的公共的资源类统一放到了基础层。

传统三层架构向DDD分层架构的演进，体现的正是领域驱动设计思想的演进。