目录
- DDD简介
- DDD是啥
- DDD能给微服务带来什么
- 不用DDD的常见设计方式
- DDD整洁架构
- 常见三层架构设计
- 整洁架构
- DDD感悟
- DDD基础概念
- 服务、实体与值对象、贫血模型/充血模型
- 服务
- 实体与值对象
- 贫血模型/充血模型
- 聚合、仓库与工厂
- 聚合
- 仓库
- 工厂
- 界限上下文
- 服务、实体与值对象、贫血模型/充血模型
- DDD实践
- DDD整体设计流程
- 战略设计
- 战术设计
- 整洁架构实战
DDD简介
DDD是啥
- 领域驱动设计（Domain Driven Design - DDD）起源于2004年Eric Evans出版《领域驱动设计》。国内对DDD的应用还是比较少，主要还是偏理论方便的介绍。
DDD能给微服务带来什么
- 随着业务的复杂化，需要有一套成熟的方法论指导业务的设计。帮助业务完成对复杂业务的设计，并实现单一职责，开闭原则，依赖倒置原则等设计模式六大原则
不用DDD的常见设计方式
-
产品需求定稿 -> 研发设计 -> 数据库设计指导程序设计
数据库涉及指导程序设计.png
- 以数据库设计为指导劣势:
- 以数据库设计为指导，会导致各个模块割裂，相互独立，随着业务越来越复杂，各个模块难免有各种各样的交互。
- 数据库描述的是数据的数据结构，而不是整个系统对数据的处理，不够体系化
DDD整洁架构
常见三层架构设计
- 三层架构设计(controller -> service -> dao)，三层架构的设计强依赖底层技术的实现，那就导致我们经常吐槽一些古董级代码，这些代码技术老旧，又改不动。往后推十年可能我们现在的一些数据库持久化技术比如mybatis, herbinate等也会被十年后的人认为是老旧框架。
- 如果有一种方法论，能够将业务与技术抽离出来，使得随着技术的迭代，业务只需要简单操作(比如升级jar包等)，就可以用上最新技术带来的好处，那就不会有业务被技术所限制，业务就能够主导。整洁架构孕育而生。
整洁架构
-
整洁架构的设计思想是业务领域模型只依赖接口，比如数据库持久化，只依赖dao接口(也常被叫做防腐层)，具体实现可以由技术中台实现，如果需要替换底层技术实现，那升级下jar包等手段做到无缝链接。
只依赖接口.png
-
整洁架构也叫洋葱头架构（The Clean Architecture）是 Robot C. Martin 在《架构整洁之道》中提出来的架构设计思。各个层面解析：
整洁架构.png
- 整洁架构业务实体(黄色)和业务应用(红色)是整个应用的核心, 业务实体就是那些核心业务逻辑，而业务应用就是面向用户的那些服务(service)。业务实体和业务应用组成了业务领域层，也就是通过领域模型形成的业务代码的实现。
- 整洁架构的最外层是各种技术框架，比如ui, db, mq, redis等
- 整洁架构的精华在于其中间的适配器层(青色)，适配器将核心的业务代码跟外围的技术框架进行解耦。设计适配层，让业务代码与技术框架解耦，让业务开发团队与技术架构团队各自独立地工作，成了整洁架构落地的核心。
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整体设计流程
- 以在线订餐为例
战略设计
-
事件风暴先分析出所有业务事件，比如下单。需要领域专家参与，统一业务语言。所以这块要求就比较高，一般公司难以实现。
事件风暴.png
-
划分界限上下文
划分界限上下文.png
战术设计
- 各个界限上下文的领域建模
-
这里区别常用的数据库驱动建模，体现了整体，更宏观角度
领域建模.png
- 如果要完全按照DDD的思想，那这时候要技术中台支持业务将，业务与技术抽离，就是业务持久化只调用防腐层，类似接口，实现可以技术中台提供jar等方式。但是这样对技术中台要求很高，所以一般这步还是没实现防腐层，会沉淀业务到业务中台。
- 各个界限上下文领域建模后就是数据库以及微服务的设计了。
整洁架构实战
- 技术中台提供相应能力，这块要求比较高，一般只学习其思想。但是整洁架构防腐层带来的好处就是，未来几年技术的迭代更新，业务层不需要或者微小改动就可以享受技术带来的好处。而不用被我们抱怨之前的项目技术太老了，改不动。
参考文章
- 本文大量参考了拉钩教育DDD微服务落地实战课程
- DDD整洁架构和六边形架构
- DDD领域驱动设计之聚合根、实体、值对象
- 领域驱动设计（DDD）在百度爱番番的实践
- 京东平台研发：领域驱动设计（DDD）实践总结
- 如何构建基于 DDD 领域驱动的微服务？
网友评论