一、领域驱动设计

领域驱动设计是⼀一种处理理⾼高度复杂域的设计思想， 试图通过分离技术实现的复杂性, 围绕业务概念构建 领域模型来控制业务的复杂性，以解决软件难以理理解， 难以演化等问题。

1、领域驱动设计三原则

• 聚焦核心领域
• 通过协作迭代式探索模型
• 使用统一语言

2、子域

一个业务领域或子域是一个企业中的业务范围以及在其中进行的活动。一个业务领域和子域可以包括多个业务能力，一个业务能力对应⼀个服务:

• 核⼼子域指业务成功的主要促成因素，是企业的核心竞争⼒
• 通⽤用子域不不是核心，但被整个业务系统所使用
• 支撑⼦域不是⼼心，不被整个系统用，完成业务的必要能力，但不是业务成功的原因

3、领域驱动设计中的战略略设计

主要指从高层“俯视”我们的软件系统，帮助我们精准地划分领域以及处理各个领域之间的关系。

重要概念

• 问题空间 Problem Space
• 解决方案空间 Solution Space
• 子域 Subdomain
  • 核心域 Core Domain
  • 支撑子域 Supporting Subdomain
  • 通用子域 Generic Subdomain
• 限界上下文 Bounded Context
• 上下文映射 Context Mapping
• 统一语言 Ubiquitous Language

4、领域驱动设计中的战术设计

主要是指从技术实现的层面教会我们 如何具体地实施DDD

重要概念

• 聚合
• 实体
• 子对象
• 领域服务
• 领域事件
• 分层架构
• 工厂
• 资源库

5、实施步骤

1. 团队消化业务知识 -> 建立统一语⾔言
2. 初步提炼领域模型 -> 识别领域模型
3. 分解领域模型复杂度 -> 划分⼦子域和限界上下⽂
4. 细分领域模型内部元素 -> 识别实体值对象和聚合根

二、事件风暴工作坊

1、流程

• 事件风暴
• 命令风暴
• 寻找领域模型
• 划分限界上下文

2、构建愿景

模式	例子
对于	消费者市场
是	网络商场式的购买平台
它可以	买货、退货、发布商品、电子支付
而不像	实体店
这个产品	随时随地安全的购物

3、事件风暴

使⽤用事件⻛风暴暴梳理理业务流程，建⽴立领域模型，划分边界

3.1 领域事件

一个领域事件必须对业务有价值，有助于形成完整的闭环，一个领域事件将导致进一步的业务操作

捕获所建模领域中发生的事情

• 领域专家关心的事件，业务上真实发生的事件
• 有时间顺序

3.2、事件风暴流程

设计业务场景(根据产品愿景与价值定位，设计关 键场景，找出起点与终点)

活动介绍，以下3步

找出领域事件

• 根据设计的业务场景，将领域事件写在即时贴上
• 每个即时贴一个事件
• 事件采⽤用“xx已xx”的格式，如“订单已 创建”

事件顺序

• 将⾃自⼰己的事件贴纸贴在⽩白板纸上
• 每个事件从左到右按时间顺序排列
• 不不同事件需保证相对顺序

事件排序

• 将⾃己的事件贴纸贴在⽩板纸上
• 每个事件从左到右按时间顺序排列
• 不同事件需保证相对顺序

4、命令风暴

产⽣生事件的领域⾏行行为或领域活动，命令可以是

• ⽤户的动作(用户从UI界面进行的操作)
• 外部系统触发
• 定时任务

活动介绍

5、寻找领域模型

识别业务含义名词、相同名词合并

5.1、找出领域模型

通过分析前⼀一步产⽣生的领域事件寻找领域模型

• 识别事件中有业务含义的名词
• 将含有相同名词的事件合并
• 确保名词代表的业务概念清晰完整且没有歧义
• ⽤大黄色即时贴进行标记

5.2、聚合

聚合是一组相关领域模型的集合，是用来封装业务的不变性。通过定义对象之间清晰的所属关系和边界确保关联关系紧密的领域模型能够内聚在一起。 从⽽避免错综复杂的对象关系⽹的形成，确保业务规则在领域对象的各个生命周期都得以执行:

• 聚合保证边界内的领域对象的业务不变性(invariant)
• 聚合内部的领域对象具有一致的生命周期

活动介绍

5.3 提炼子域

目的：

• 回到问题域，验证解决⽅方案
• 定义模型与子域的对应关系， 聚焦识别核心模型与核心子域

活动介绍

5.4、实体和值对象

5.4.1 实体

是一类对象，它拥有全局唯一标识符，且标识符在历经软件系统的各种状态、 生命周期后仍能保持一致。我们把这样的 对象称为实体 。

• 具有生命周期
• 有唯一标识符
• 通过ID判断相等性
• 增删改查/持久化
• 可变
• 比如Order/Car

5.4.2 值对象

我们对某个对象是什么不感兴趣，只关心它拥有的属性。用来描述领域的特 殊方面、且没有唯一标识符的对象叫做值 对象。

• 起描述性作用
• 无唯一标识符
• 通过属性判断相等性
• 实现Equals()方法
• 即时创建/用完即扔
• 不可变
• 比如Address/Color

5.4.3 活动介绍

6、划分限界上下文

利用领域驱动设计的战略设计⽅法，划分边界

6.1 定义

限界上下文可以分为限界和上下文两个词来理解

限界:指一个界限，具体的某一个范围
上下⽂文:场景、环境

所以限界上下文是在某个场景或环境下的业务边界。该边界就是业务上的职责

6.2 原则

6.2.1 术语相同，含义不同

消除歧义的最好办 法就是在上下文图中，将领域模型分拆在 多个界限上下文中

6.2.2 概念相同，用法不同

6.2.3 外部系统

6.2.4 活动介绍

6.3 上下文映射

利用领域驱动设计的战略设计方法，划分边界

通过定义不同上下文之间的关系，创建的一个所有模型上下文的全局视图

• 可以⽤用于架构分析，造成集成瓶颈的架构问题
• 展现了组织动态的能⼒，帮助我们识别出阻碍项目进展的一些管理(协作和沟通)问题
• 保持简单，促进沟通

三、微服务和DDD

1、微服务设计原则

1. 对齐限界上下⽂
2. 业务变更频率与相关度
3. 系统非功能性需求
4. 组织结构
5. 团队规模
6. 技术异构和现有系统复杂度

2、微服务拆分原则

备注

一、软件开发本质

graph LR
A[程序员] --> |最重要的素质| B[学习能力]

C[程序] --> |易改| D[完成功能]
C[程序] --> |易改| F[可维护]
   

把人类语言（需求）转化成猿类语言（电脑懂的语言）

graph LR
A[软件开发] --> |本质| B[学习]

二、战略和战术

graph LR
A{战略}
    A --> F[大]
    A --> G[方向]
B{战术}
    B --> D[小]
    B --> E[实施]

三、架构就是Drawing Lines