【PPT】演进式DDD🚀 -

# 演进式DDD🚀
> 作者：罗恒全 东软TSD

💣你被DDD困住了吗？
带你认识不一样的DDD🌈

---

## CRUD Boy三宗罪
Java作为面向对象的编程语言，使用Java编程的你面向对象了吗？

Mybatis
贫血模型
事务脚本

---

#### 一个关于拆解、微服务、面向对象的故事

![img](/assets/img/in-post/ddd/oo.png)

#### 类间的关联关系
![img](/assets/img/in-post/ddd/oo_refactor_1.png)

## 分包提升内聚、包内指定入口类降低耦合
![img](/assets/img/in-post/ddd/oo_refactor_2.png)

#### 给这个故事起个新的名字 - DDD
![img](/assets/img/in-post/ddd/ddd.png)

#### 拆解维度对比
| 微服务、面向对象的拆解维度 | DDD的拆解维度（战略 & 战术） |
|:-------------------------------------------------------|:------- |
| 子系统 重要、次重要、通用 | 子域 核心域、支撑域、通用域 | 
| 微服务及其交互 进程通信、事件驱动架构 | 限界上下文及其映射关系 防腐层ACL/开放主机服务OHS、事件驱动架构EDA |
| 面向对象 包、入口类、自定义属性类、对象仓库、交互出口接口、 服务编排类、业务编排类 | 领域建模 聚合、聚合根/实体、值对象、仓库、ACL接口、 应用服务、领域服务 |

---

#### D3S分层架构
![img](/assets/img/in-post/ddd/d3s.png)

#### Talk is cheap, show me the code.

- 源码地址：[https://gitee.com/luoex/d3s](https://gitee.com/luoex/d3s)
- D3S（DDD with SpringBoot）为本作者使用DDD过程中开发的框架及示例

---

#### 事务脚本 VS DDD

![img](/assets/img/in-post/ddd/ts_createGoods.png)

![img](/assets/img/in-post/ddd/ddd_createGoods.png)

![img](/assets/img/in-post/ddd/ts_updateGoods.png)

![img](/assets/img/in-post/ddd/ddd_updateGoods.png)

---

#### DDD中常提到的应用架构
![img](/assets/img/in-post/ddd/hexagon.png)

![img](/assets/img/in-post/ddd/clean.png)

![img](/assets/img/in-post/ddd/explict.png)

---

## 识别子域

- 核心域
 - 重要的，最能体现业务价值的
- 支撑域
 - 相对来说不那么重要的，但却对核心业务起到了支撑作用
- 通用域
 - 通用的子系统，被其他多个子系统用到，又或者可作为后续团队技术资产用于其他项目的子系统

#### 关于子域的映射问题
- 关于 子系统 和 子域 的映射，可能不一定十分恰当，  
- 子域是偏向上层（问题空间）的业务划分，而子系统则比较偏向系统实现的划分，  
- 但是大家都是对业务系统的拆解，只要能对系统进行合理的拆解，叫什么名字又有什么关系，子系统、模块…还是子域，  
- 我们做的设计最终都是要指导落地的，搞那么多迷惑性的概念和拆解除了能让PPT上多一些谈资，似乎给指导落地并不能带来任何实质性的帮助。

## 核心域
- 重要的，最能体现业务价值的
- 技术大牛团队负责，保证质量，开个好头，也能体现出咱们团队的能力
- 使用DDD分层架构

## 支撑域
- 相对来说不那么重要的，但却对核心业务起到了支撑作用
- 不那么重要的可以分给咱们其他的团队来做，如果人手不够也可以交由外包团队来做
- 可以使用事务脚本

## 通用域
- 通用的子系统，被其他多个子系统用到，又或者可作为后续团队技术资产用于其他项目的子系统
- 通用的子系统咱么可以自己做，也可以采购一些现成的解决方案。

---

## 识别限界上下文
限界上下文即微服务
业务边界（领域逻辑层面）
组织边界（团队合作层面）
技术边界（技术实现层面）

#### 业务边界（领域逻辑层面）
- 具体的业务逻辑边界
- 商城子系统中的订单、商品、售后、物流等模块，
- 车载即时通信子系统的用户及车友、聊天、通信等模块
- 营销管理子系统的线索管理、销售助手、客服管理等模块
- 系统的菜单结构，例如一、二级菜单，则一级菜单包含的子业务可以作为一个模块等

#### 组织边界（团队合作层面）
- 康威定律，组织结构决定软件结构
- 例如公司开发团队分为商品部、订单部、售后部，那这个三个维度就可以独立为单独的限界上线文
- 例如服务平台团队包含基础服务组、服务池组、架构支撑组，我会将系统中通用的服务如用户权限管理、短信通知、客服管理等服务都分配给基础服务组来完成，而一些涉及到具体业务的服务交由服务池团队来完成，而涉及到纯技术维度的实现则交由架构支撑组来完成

#### 技术边界（技术实现层面）
- 性能要求（高并发、实时…）
- 功能重用（或者 通用功能）
- 第三方服务集成
- 遗留系统

#### 限界上线文（微服务）拆分标准
- 多扇入少扇出
 - 当耦合不可避免时，尽量做到服务可以被别的服务依赖，但是尽量少去依赖别的服务
 - 这个多与少的度则由服务间的交互接口数量、组织间的沟通成本来界定的
 - 这块没有绝对的标准，完全由团队的能力、默契度等决定，需要经过团队不断磨合、演进、重构才能越来越契合

#### 限界上线文（微服务）拆分 - 我的建议
- 在敏捷开发的时代，响应变化胜过遵循计划
- 可以先根据之前提到的业务、组织、技术三个维度对整个系统进行第一轮的服务拆解，整体上保证服务拆分的合理性
- 然后在不断迭代的过程中再进行优化和调整，力求达到业务与应用工程间的平衡

---

#### 限界上下文间的映射关系（服务间交互）
- 大泥球（Big Ball of Mud） 一个大的混杂的系统，已经无法在内部梳理清楚了（大泥球、黑盒、边界、接口可用）
- 合作关系（Partnership） 两个上下文紧密合作的关系，一荣俱荣，一损俱损。他们需要一起协调开发计划和集成管理。
- 遵奉者（Conformist） 供应方不能配合开发，导致下游只能盲目的使用上游的模型。
- 客户方-供应方开发（Customer-Supplier Development） 客户方(D)提需求，供应方(U)配合做开发，供应方发生变更时下游也需要跟着修改。
- 共享内核（Shared Kernel） 两个上下文依赖部分共享的模型。

- 开放主机服务（Open Host Service） 定义一种协议来让其他上下文来对本上下文进行访问，如公开的Http服务。
- 防腐层（Anticorruption Layer） 一个上下文通过一些适配和转换与另一个上下文交互。
- 发布语言（Published Language） 一种公共语言，用于两个限界上下文之间的模型的转换（Controller层的DTO、ACL层的DTO），避免不同限界上下文间领域模型的泄露与耦合。
- 事件驱动架构（Event-Driven Architecture） 多个限界上线文（或者 微服务间）采用消息中间件进行通信，通信过程中传递的消息即对应领域事件DomainEvent（又或者ApplicationEvent）
- 完全分离（SeparateWay） 两个完全没有任何联系的上下文。

---

## 聚合
- 聚合是包含了实体和值对象的—个边界
- 聚合内包含的实体和值对象形成-棵树，只有实体才能作为这棵树的根。这个根称为聚合根，这个实体称为根实体
- 外部对象只允许持有聚合根的引用, 以起到边界的控制作用
- 聚合作为一个完整的领域概念整体，其内部会维护这个领域概念的完整性，体现业务上的不变量约束
- 由聚合根统一对外提供履行该领域概念职责的行为方法，实现内部各个对象之间的行为协作

## 识别聚合
![img](/assets/img/in-post/ddd/aggr_rule.png)

## 聚合与面向对象的关系
| 实体类间关系 | 聚合划分 |
|:-----------|:----------------------------------------|
| 泛化 | 子类无新增属性 - 父类作为聚合 子类新增属性 - 各子类分别成为聚合 |
| 关联 | 不同聚合 |
| 组合 同生共死 | 同一聚合 |
| 聚合 | 不同聚合 |
| 依赖 | 不同聚合 |

## 聚合间的协作
| 聚合范围                  | 协作方式                         |
|:----------------------|:-----------------------------|
| 同聚合下的不同实体、值对象         | 对象关联（对象引用）                   |             
| 同一限界上下文中的不同聚合下的不同聚合根  | 通过ID关联、依赖（方法参数、创建）、应用/领域服务编排 |
| 不同限界上下文中的不同聚合根 | 通过应用/领域服务编排                  |

## 实体 & 值对象
![img](/assets/img/in-post/ddd/entity_vo.png)

#### 商品聚合示例
![img](/assets/img/in-post/ddd/goods_aggr.png)

---

## 仓库
- 在聚合中选择一个实体作为聚合根（入口类），对该聚合的访问均通过聚合根发起
- 一个聚合对应一个仓库Repository，即由聚合内的仓库负责对聚合根进行持久化操作
- 如果要访问聚合内的非根实体，也只能通过仓库获得整个聚合根，将聚合根作为入口，在内存中访问封装在聚合边界内的非根实体对象
- 同时由于仓库对应领域层的领域模型，所以仓库接口的定义通常也仅依赖领域层的领域对象（实体、值对象）

## 仓库 - Mybatis & Spring Data JPA

- 2段式设计 - Mybatis
- 1.5段式设计 - Spring Data JPA【推荐】
- ROM & ORM

## 仓库 - Mybatis（2段式）
- 首先我们在领域层投入了大量的精力对领域模型进行设计和梳理，精益求精，完成了第一段设计
- 但是这还不够，然后我们又在基础设施层再进行了一次适配领域模型的数据库设计，费心费力地完成了面向对象和实体关系间的转换，完成了第二段设计
- 再然后就是各种在领域模型和数据对象之间的转换，仓库和DAO之间的协调，不厌其烦…
- 到最后悲催的只能是程序员😭：领域模型我得写，事务脚本也没丢，双倍的工作量下还得协调二者的转换

#### 仓库 - Mybatis（2段式）
![img](/assets/img/in-post/ddd/repo_mybatis.png)

#### 仓库 - Mybatis（2段式）的问题
- 可能有的人会跟你说隔绝领域模型和仓库实现模型是为了隔离技术的变化，避免技术侵入到领域建模中，如此即便有一天我们底层仓库实现切换成不同的存储也不会影响上层领域建模。

- 如此说没有问题，那我又忍不住想问：
  - 后续上线的系统会轻易切换底层存储实现吗？切换的代价和风险是可承担的范围内吗？
  - 已经使用了关系型数据库作为存储，后续还会切换其他类型的非关系型数据库吗？
  - 要是短期内都没有切换底层存储的打算，那我们能不能不那么过度设计，等真正需要切换的时候再去付出工作量呢？

- 如果系统架构的一开始就确定后续会有切换底层存储实现的可能，那么你付出如此多的代价来隔离领域模型和仓库实现模型是有意义的，保证了领域模型的纯粹性，也即常说的PI(persistence ignorance，持久化透明)
- 但如果底层存储使用关系型数据库且近期内不确定是否有切换底层存储的打算，那么我更推荐一种1.5段式的设计，即集成Spring Data JPA

## 仓库 - Spring Data JPA（1.5段式）
- 将领域模型和数据模型合二为一，如此避免了领域模型和数据对象间的各种手动编码的转换，具体的ORM转换则由专门JPA框架实现（如Hibernate）来完成，也使得开发人员更专注于领域建模
- 完成领域模型的建模后可借助Hibernate自动生成数据库DDL定义，也避免了我们再去重新设计一遍数据库，而是在自动生成的DDL基础上进行调整
- 领域层的仓库接口可继承Spring Data JPA中内置的Repository接口自动完成实现的注入，避免我们再去编写大量的仓库实现代码

#### 仓库 - Spring Data JPA（1.5段式）
![img](/assets/img/in-post/ddd/repo_jpa.png)

#### 仓库 - Spring Data JPA（1.5段式）
![img](/assets/img/in-post/ddd/spring_data_jpa_repo.png)

## 仓库 - Spring Data JPA（1.5段式）的问题
- 虽然JPA注解侵入到了领域模型，但是对领域模型的结构、关系并没有影响，况且JPA不依赖具体实现框架，仅凭注解也不会给我们的领域模型带来其他的附加作用
- 领域层的仓库接口依旧是接口的形式，上层（ApplicationService、DomainService）的调用也仅是依赖抽象接口，并未依赖具体实现，即便后续真要切换不同的底层存储了，那我们再去具体实现该接口便可以了

## 仓库 - Spring Data JPA（1.5段式）的问题
- 国产数据库适配，观望中😅...
- 有人说JPA不好学，那我也没啥可说的了，学习中...
- 有人说JPA太重，想关注领域模型、还是数据模型你自己选
 - 你想要绝对的数据性能，那你使用Mybatis和事务脚本挺好的
 - 你想要关注领域建模，那你使用领域驱动设计和Spring Data JPA，香...
 - 你又想关注领域又想数据性能，那有可能真的耗不起...

---

## 创建聚合根（对象工厂）
>区分 构造函数 & 初始创建

Factory
Assembler
DTO
Domain

## Factory
![img](/assets/img/in-post/ddd/goods_factory.png)

## Assembler
![img](/assets/img/in-post/ddd/order_assembler.png)

---

## Always-Valid Domain Model
验证逻辑应该放在哪层？
接口层(MvcController)
应用层(AppService)
领域层(Entity、ValueObject)

## Always-Valid Domain Model
- 应该由领域模型来保证自身的有效性
- 应用层 - 调用Specification处理复杂验证（调用Repository、ACL）
- 领域层 - 基础验证（非空、长度、格式...）

## Always-Valid Domain Model
Constructor Validation
Method Validation
Java Validation Annotation

#### Always-Valid Domain Model
![img](/assets/img/in-post/ddd/domain_validate.png)

#### Always-Valid Domain Model
![img](/assets/img/in-post/ddd/domain_validate_impl.png)

---

##  Specification
![img](/assets/img/in-post/ddd/specification.png)

#### Specification实现
![img](/assets/img/in-post/ddd/specification_impl.png)

#### Specification结合Always-Valid Domain Model
![img](/assets/img/in-post/ddd/specification_validation.png)

---

## 领域事件
- 在一个领域中所发生的一次对业务有价值的事情
- 落到技术层面就是在一个业务实体对象(通常来说是聚合根)的状态发生了变化之后需要发出一个领域事件
- 推荐应用事件替代领域事件，避免领域对象序列化问题

#### D3S领域事件
![img](/assets/img/in-post/ddd/d3s_eda_class_diagram.png)

#### D3S EDA
![img](/assets/img/in-post/ddd/d3s_eda_arch.png)

---

## CQRS
- 解决领域模型不适合做汇总查询的问题
  - 组装仓库查询 - 将查询逻辑与业务逻辑糅合在一起会使软件迅速腐化，诸如逻辑混乱、可读性变差以及可扩展性降低等等
  - 聚合根间仅通过ID进行关联，若想查询完整信息不支持，所以只能单独建立查询模型
  - 统计查询（数据聚合）无法对应到领域模型，所以只能单独建立统计查询模型
- 对于查询效率要求较高的场景
- Command/Query分开处理 - 读写分离

## CQ分离形式
![img](/assets/img/in-post/ddd/cq_separate.png)

#### CQRS适用场景
![img](/assets/img/in-post/ddd/cqrs_scene.png)

#### 单服务跨聚合 - 分离存储/分离模型
![img](/assets/img/in-post/ddd/cqrs_ssma.png)

#### 跨服务跨聚合 - 分离存储/分离模型
![img](/assets/img/in-post/ddd/cqrs_msma.png)

## 轻量化CQRS
- [轻量化的CQRS实现（共享存储/分离模型）](https://learn.microsoft.com/en-us/dotnet/architecture/microservices/microservice-ddd-cqrs-patterns/apply-simplified-microservice-cqrs-ddd-patterns)
 - Application CommandService(Command) - 调用Repository
 - Application QueryService(Query) - 调用DAO
- Repository整合Command、Query
 - 我个人还是倾向于仓库整合CQRS，即既包含领域模型、也包含查询模型，如此虽然突破了层次的限制，但是给开发维护带来了极大的便利性

---

## 跨越层次限制
> 允许Application层侵入到Domain层

| 模型   | 说明                                           |
|:----------|:-----------------------------|
| Factory   | Application.DTO侵入到Domain.Factory中            |
| Repository   | Application.Query侵入到Domain.Repository中       |
| Domain | Application.Command侵入到Domain.AggregateRoot中 |

---

## 跨越模型的限制

| 模型   | 适用场景                      |
|:----------|:--------------------------|
| DDD | 领域模型、面向对象                 
| 面向数据库 | 批量修改                      |
| CQRS  | Repository整合Command、Query | 
| 应用事件 | 替代领域事件，避免序列化问题      |

---

## DDD WITH C4 - C1
![img](/assets/img/in-post/ddd/d3s_c1.png)

## DDD WITH C4 - C2
![img](/assets/img/in-post/ddd/d3s_c2.png)

## DDD WITH C4 - C2
![img](/assets/img/in-post/ddd/d3s_c2_bc.png)

## DDD WITH C4 - C3
![img](/assets/img/in-post/ddd/d3s_c3.png)

---

## 总结
- 不要为了DDD而DDD，尤其对于初学者不要上来就去学习DDD中的各种迷惑性的概念和术语
- 只有建立在理解的基础上，充分理解了各种模式的使用场景及动机，才能真正发挥各种模式的优势，放下DDD也许你才能真正体会到DDD
- 在我眼中，DDD是面向对象编程经过合理重构后应该会出现的样子
- 但是DDD不是银弹（世上没有万能药），全DDD不如无DDD

- 奥卡姆剃刀原理 - 如无必要，勿增实体
  - 先不要上来就创建那么多值对象，适当的可通过实体、领域服务进行行为的代替
- 取长补短，适当变通
- 拥抱Spring Data JPA
- 以提升代码可维护性、研发效率为目标

</textarea>