1.7 DDD

1. 什么是DDD

领域驱动设计，是一种架构方法

1.1. 领域

1.1.1. 什么是领域

领域就是业务的范围/边界，大领域可以划分成多个中领域，中领域又可以继续划分成小领域… 本质就和解决问题一样，采用分而治之的思想把复杂问题简单化，从而降低业务理解和系统实现的复杂度

1.1.2. 为什么需要领域

用来确定业务边界和范围的。在微服务中每个领域都可以当作一个服务

1.1.3. 子域的分类

1.1.3.1. 核心子域

决定产品核心竞争力的功能子域

1.1.3.2. 通用子域

没有太多个性化诉求，同时又会被多个子域重复使用的通用功能子域是通用子域

1.1.3.3. 支撑子域

除去核心子域和通用子域的其他子域就是支撑子域

1.2. 通用语言和限界上下文

1.2.1. 什么是通用语言

描述同一个领域内的对象的统一语言

1.2.2. 为什么需要通用语言

• 解决交流的障碍
• 用于微服务代码落地实现，领域模型可以直接映射到代码模型

1.2.3. 什么是限界上下文

语言+语义环境->唯一含义 限界上下文相当于语义环境，在业务中也就是业务边界

1.2.4. 为什么需要限界上下文

确定通用语言所在的环境，保证通用语言描述的对象没有歧义

1.2.5. 限界上下文 vs 领域

限界上下文本质就是领域，两者只是从不同维度描述了业务边界 限界上下文是解决方案的角度，通过事件风暴确定领域对象，进而指导微服务落地 领域则是问题的角度，把大问题分解成小问题

1.3. 实体和值对象

都是领域模型中的领域对象（DO）

1.3.1. 什么是实体

Entity，对应业务对象，具有业务属性和业务行为 代码形态：拥有唯一的ID，除了包含属性和getter、setter方法，还有一些方法实现实体自身的业务逻辑。其实就是充血模型 数据库形态：一个实体可能对应0个、1个或者多个数据库持久化对象

1.3.1.1. 充血模型 vs 贫血模型

1.3.2. 为什么需要实体

1.3.3. 什么是值对象

VO，属性的集合，对实体的特征进行描述 代码形态：除了包含属性和getter、setter方法，没有其他包含业务逻辑的方法 数据库形态：属性嵌入或者序列化大对象

1.3.4. 为什么需要值对象

避免属性零散在业务对象中

1.4. 聚合

1.4.1. 什么是聚合

有业务逻辑耦合的实体和值对象组成

1.4.2. 为什么需要聚合

高内聚，低耦合

1.4.3. 什么是聚合根

一个聚合有且仅有一个聚合根，他是用来管理聚合内的其他实体和值对象的实体，用来管理聚合内的其他实体和值对象

1.4.4. 为什么需要聚合根

为了保证数据一致性，所有访问聚合的外部请求都有聚合根处理

1.5. 领域事件

1.5.1. 什么是领域事件

领域内发生的事件，一个领域事件将导致进一步的业务操作，在实现业务解耦的同时，还有助于形成完整的业务闭环。

1.5.2. 为什么需要领域事件

异步+解耦 如何设计异步系统.md

1.5.3. 如何设计领域事件

1. 事件构建和发布

//事件基类
type DomainEvent struct {
    id string//事件唯一标识
    timestamp int64//发生时间
    source string//事件类型
    data interface{}//事件源
}

2. 事件数据持久化
   • 方案一：持久化到业务数据库中。优点：一致性。缺点：耦合
   • 方案二：持久化到单独的事件数据库中。优点：解耦。缺点：分布式事务
3. 事件总线
   • 微服务内部使用发布者订阅者模式
   • 微服务之间使用持久化并异步发送给消息中间件
4. 事件接收和处理

1.6. 仓储模式与工厂模式

仓储模式用于DO对象的持久化，使得业务逻辑和基础资源逻辑解耦，实现依赖倒置 工厂模式用于创建DO对象或者DO对象和PO对象的转换，使得与业务无关的代码从聚合根中剥离

2. 为什么需要DDD

解决软件规模化的问题 指导微服务架构下服务的设计和拆分

3. 如何设计DDD

3.1. 事件风暴

3.2. 领域故事分析

3.3. 提取领域对象

3.4. 领域对象与代码模型映射

3.5. 代码落地

4. DDD微服务实例

• ouchuangxin/leave-sample: 本代码来源于极客时间《DDD实战》专栏。

5. 参考

• DDD实战课 · 捕风的逍遥侯/geek_crawler - 码云 - 开源中国
• 基于DDD微服务架构分层设计_哔哩哔哩_bilibili
• 00 开篇词 让我们把 DDD 的思想真正落地.md