目录

• DDD简介
  • DDD是啥
  • DDD能给微服务带来什么
    • 不用DDD的常见设计方式
  • DDD整洁架构
    • 常见三层架构设计
    • 整洁架构
  • DDD感悟
• DDD基础概念
  • 服务、实体与值对象、贫血模型/充血模型
    • 服务
    • 实体与值对象
    • 贫血模型/充血模型
  • 聚合、仓库与工厂
    • 聚合
    • 仓库
    • 工厂
  • 界限上下文
• DDD实践
• DDD整体设计流程
  • 战略设计
  • 战术设计
• 整洁架构实战

---

DDD简介

DDD是啥

• 领域驱动设计（Domain Driven Design - DDD）起源于2004年Eric Evans出版《领域驱动设计》。国内对DDD的应用还是比较少，主要还是偏理论方便的介绍。

DDD能给微服务带来什么

• 随着业务的复杂化，需要有一套成熟的方法论指导业务的设计。帮助业务完成对复杂业务的设计，并实现单一职责，开闭原则，依赖倒置原则等设计模式六大原则

不用DDD的常见设计方式

• 产品需求定稿 -> 研发设计 -> 数据库设计指导程序设计

  
  数据库涉及指导程序设计.png
• 以数据库设计为指导劣势:

1. 以数据库设计为指导，会导致各个模块割裂，相互独立，随着业务越来越复杂，各个模块难免有各种各样的交互。
2. 数据库描述的是数据的数据结构，而不是整个系统对数据的处理，不够体系化

DDD整洁架构

常见三层架构设计

• 三层架构设计(controller -> service -> dao)，三层架构的设计强依赖底层技术的实现，那就导致我们经常吐槽一些古董级代码，这些代码技术老旧，又改不动。往后推十年可能我们现在的一些数据库持久化技术比如mybatis, herbinate等也会被十年后的人认为是老旧框架。
• 如果有一种方法论，能够将业务与技术抽离出来，使得随着技术的迭代，业务只需要简单操作(比如升级jar包等)，就可以用上最新技术带来的好处，那就不会有业务被技术所限制，业务就能够主导。整洁架构孕育而生。

整洁架构

• 整洁架构的设计思想是业务领域模型只依赖接口，比如数据库持久化，只依赖dao接口(也常被叫做防腐层)，具体实现可以由技术中台实现，如果需要替换底层技术实现，那升级下jar包等手段做到无缝链接。

  
  只依赖接口.png

• 整洁架构也叫洋葱头架构（The Clean Architecture）是 Robot C. Martin 在《架构整洁之道》中提出来的架构设计思。各个层面解析：

  
  整洁架构.png

1. 整洁架构业务实体(黄色)和业务应用(红色)是整个应用的核心, 业务实体就是那些核心业务逻辑，而业务应用就是面向用户的那些服务(service)。业务实体和业务应用组成了业务领域层，也就是通过领域模型形成的业务代码的实现。
2. 整洁架构的最外层是各种技术框架，比如ui, db, mq, redis等
3. 整洁架构的精华在于其中间的适配器层(青色)，适配器将核心的业务代码跟外围的技术框架进行解耦。设计适配层，让业务代码与技术框架解耦，让业务开发团队与技术架构团队各自独立地工作，成了整洁架构落地的核心。

DDD感悟

• DDD是解决复制业务，微服务架构的方法论，但是整个战略设计战术设计过程中，对于研发而言除了自身知识广度要够，还需要有熟悉业务的业务专家，还需要有强大的技术中台。所以要完全实现DDD的设计思想，对公司的要求还是比较高，大部分情况下，我们可以借鉴DDD设计思想，结合公司整体情况，有机的将DDD与公司现有系统相结合，不必照搬。本篇主要是介绍DDD的设计思想。

---

DDD基础概念

服务、实体与值对象、贫血模型/充血模型

服务

• 标识的是那些在领域对象之外的操作与行为，比如下单，前端发起下单请求，service服务收到之后，对下单实体校验参数，执行下单持久化，然后发送mq。

实体

• 唯一标识字段来区分真实世界中的每一个个体的领域对象，比如学校系统的学员，学员是一个实体有各个属性，班级，性别之类的

值对象

• 一成不变的对象，比如教师是一种职业，福建是省份。

贫血模型，充血模型

• 贫血模型: 一堆的pojo, 只有get set方法，没有其他的了，比较常用这种，实现也比较简单，更好应对复杂业务，

• 充血模型，业务方法放在领域对象里面，service服务只干简单的事情就是调用领域对象方法。充血模型对多态，封装的特性用的很好。如果有类型或者编码进行转换可以用充血模型。借鉴拉钩教育DDD课程图，充血模型设计和好的实现了多态。

  
  DDD充血模型.png

聚合、仓库与工厂

聚合

• 聚合是领域驱动设计中一项非常重要的设计与概念。聚合设计模式的组合模式表示整体与部分，比如订单与订单明细、表单与表单明细、发票与发票明细这些整体与部分。
• 创建订单，保存订单只需要处理聚合根的聚合，就可以创建订单以及订单明细，他们在一个事务里面。不能单独创建新增订单明细。
• 加载订单也是操作聚合根，这样聚合对象就能自动加载出订单以及订单明细。

仓库Repository

• 订单与订单明细的聚合是通过仓库实现的，仓库通过订单DAO，订单明细DAO查询出订单与订单明细聚合。当然也有可能有额外操作，比如加缓存。

工厂

• 订单与订单明细聚合service服务会将查询分配到仓库，仓库分配到工厂，工厂通过订单DAO，订单明细DAO查询出订单与订单明细聚合返回给仓库，仓库可能做些缓存。

界限上下文

• 借鉴拉钩教育的DDD下单界限上下文图

  
  界限上下文.png
• 可以看到用户下单是核心，也就是图中的主题目域，下单要取地址，用户要注册，那用户域就是支撑域。下单要知道饭店信息，那饭店管理就也是支撑域。

---

DDD实践

DDD整体设计流程

• 以在线订餐为例

战略设计

1. 事件风暴先分析出所有业务事件，比如下单。需要领域专家参与，统一业务语言。所以这块要求就比较高，一般公司难以实现。

   
   事件风暴.png

2. 划分界限上下文

   
   划分界限上下文.png

战术设计

1. 各个界限上下文的领域建模

• 这里区别常用的数据库驱动建模，体现了整体，更宏观角度

  
  领域建模.png

2. 如果要完全按照DDD的思想，那这时候要技术中台支持业务将，业务与技术抽离，就是业务持久化只调用防腐层，类似接口，实现可以技术中台提供jar等方式。但是这样对技术中台要求很高，所以一般这步还是没实现防腐层，会沉淀业务到业务中台。
3. 各个界限上下文领域建模后就是数据库以及微服务的设计了。

整洁架构实战

• 技术中台提供相应能力，这块要求比较高，一般只学习其思想。但是整洁架构防腐层带来的好处就是，未来几年技术的迭代更新，业务层不需要或者微小改动就可以享受技术带来的好处。而不用被我们抱怨之前的项目技术太老了，改不动。

---

参考文章

• 本文大量参考了拉钩教育DDD微服务落地实战课程
• DDD整洁架构和六边形架构
• DDD领域驱动设计之聚合根、实体、值对象
• 领域驱动设计（DDD）在百度爱番番的实践
• 京东平台研发：领域驱动设计（DDD）实践总结
• 如何构建基于 DDD 领域驱动的微服务？