子域
概念
领域按照一定的业务规则细分, 进而划分出多个子域, 每个子域对应一个更小的业务范围
过程
把问题域逐步分解, 降低业务理解和系统实现的复杂度
分类
核心域
唯一的定义明确的领域模型, 业务的核心部分, 公司核心竞争力
通用域
系统中用到的通用系统, 例如: 认证, 权限等. 甚至可以采购现成的.
支撑域
具有企业特性, 具备"定制开发"的特性
通用语言
定义上下文的含义
在事件风暴中, 通过团队交流达成共识的, 能简单清晰准确地描述业务含义和规则的言语
注意
在说某通用语言时, 必须要限定在某个上下文内, 以确保每个上下文含义在它特定的边界内都有唯一的含义
限界上下文
定义领域边界
领域可以被拆分成多个子领域, 一个领域相当于一个问题域, 拆分的过程就是大问题拆分为小问题的过程. 每个领域模型都有他对应的限界上下文, 理论上限界上下文就是微服务的边界
实体
概念
领域模型中的实体是多个属性, 操作和行为的载体, 拥有唯一标志. 实体和值对象是组成领域模型的基础单元, DDD中采用充血模型构建实体. 使用ID即可判定两实体是否相等
值对象
概念
通过对象属性值来识别的领域对象, 将多个相关的属性组合为一个概念整体, 具有整体概念和不可修改的属性. 值对象之间使用属性值进行判断相等性.
实体和值对象的关系
实体和值对象是领域模型的最基本单元, 一起实现实体最基本的核心领域, 值对象依附于实体
聚合/聚合根
理解
聚合包含一个聚合根和上下文边界, 这个边界根据业务单一职责和高内聚原则, 定义了聚合内部应该包含哪些实体和值对象, 而聚合之间的边界是松耦合的.
领域模型中的实体和值对象好比个体, 而能让实体和值对象协同工作的组织就是聚合, 用于保这些领域对象在实现共同的业务逻辑时, 能保证数据的一致性.
业务和逻辑紧密关联的实体和值对象组合而成, 聚合是数据修改和持久化的基本单元, 每个聚合对应一个仓储, 实现数据的持久化
如何设计聚合
1. 采用事件风暴, 根据业务行为, 梳理出业务发生过程中的实体和值对象
2. 从众多实体中选出合作为对象管理者的根实体, 也叫聚合根
3. 根据业务单一职责和高内聚原则, 找出与聚合根关联的所有的紧密依赖的实体和值对象.
4. 在聚合内根据 聚合根, 实体, 值对象 的依赖关系, 画出对象的引用和依赖模型.
5. 多个聚合根据业务语义和上下文一起划分到同一个限界上下文中
聚合的设计原则
1. 在一致性边界内建模真正的不变条件: 聚合内的实体和值对象按照统一的业务规则运行, 实现数据对象的一致性
2. 设计小聚合: 降低由于业务过大导致的聚合重构的可能性.
3. 通过唯一标志引用其他聚合: 聚合之间通过关联外部聚合根id的方式引用
4. 在边界之外使用最终一致性: 在一次事务中, 最多只能更改一个聚合的状态. 若一次业务操作导致多个聚合状态的修改, 可以采用领域事件异步修改相关的聚合.
5. 通过应用层实现跨聚合的服务调用
聚合/聚合根/实体/值对象 特征
聚合特征
高内聚, 低耦合, 领域模型的最底层的边界, 甚至可以作为拆分微服务的最小单元. 但需结合实际情况;一个微服务可包含多个聚合, 聚合之间的边界是微服务内天然的逻辑边界, 在微服务架构演进的时候就可以聚合为单位进行拆分和组合了.
聚合根特征
聚合根是特殊的实体, 一个聚合仅有个聚合根, 聚合根在聚合内对实体和值对象采用直接对象引用的方式进行组织和协调 聚合根之间则通过ID关联的方式实现聚合之间的协同
实体特征
有个唯一的ID标志, 通过ID判定相等性, 状态可变, 依附于聚合根, 其生命周期由聚合根管理. 实体一般会持久化. 实体可以引用聚合内的 聚合根, 实体, 值对象.
值对象特征
无ID, 不可变, 无生命周期, 值对象之间通过属性值全等判断相对性. 核心本质是值, 是一组概念完整的属性组合的集合, 值对象尽量只引用值对象
领域事件
概念
一个领域事将导致进一步的业务操作 在实现业务解耦的同时, 还有助于形成完整的业务闭环
识别领域事件
在时间风暴中,做用户旅程 或者场景分析时, 出现类似 "如果...那么.." "发生...时, 则..." 等, 发生某种事情之后, 触发进一步的操作, 那么这个事件很有可能就是领域事件
领域事件可以切断领域模型之间的强依赖关系, 事件发布完成之后, 发布方不必关系订阅方事件处理是否成功. 实现领域模型之间的解耦, 最终保证了基于事件的一致性
使用场景
微服务内的领域事件
完成业务实体构建和命令, 事件数据的的持久化后, 按照DDD原则"一次事务只更新一个聚合", 则需要把事件发布到事件总线, 但是这样会增加复杂度. 因此需要结合应用复杂度和收益进行总和考虑
数据实时要求高的场景下, 可以在应用服务层, 可以通过跨聚合的服务编排和组合, 以服务调用的方式完成跨聚合的访问. 这个过程会用到分布式事务. 以保证发布方和订阅方的数据同时更新.
微服务间的领域事件
可以采用微服务直接调用的方式, 实现数据和服务的实时访问. 需要引入分布式事务以保证数据的一致性.
考虑: 事件构建, 发布和订阅, 事件数据的持久化.
事件风暴
概念
梳理用户旅程, 分析业务场景, 领域专家和开发人员头脑风暴的过程, 进而确定 限界上下文, 通用语言,找出实体, 值对象等 依次 进行领域分解, 建立领域模型
事件风暴的准备工作
参与者
项目团队, 领域专家(业务,架构师,产品,开发, 测试); 领域专家需要单独的说下: 对业务或者问题有深刻见解的主体专家, 例如需求分析人员, 产品经理, 或者是在这里领域多年开发经验的开发人员.
材料
事件风暴的参与者会把自己的想法和意见写在即时贴上
可用不同的颜色的贴纸区分领域行为
蓝色: 命令
绿色: 实体
橙色: 领域事件
黄色: 补充信息
关注点
重点关注某类业务的语言和行为, 比如某些业务动作或者行为是否会触发下一个业务动作, 进而可以分析出聚合, 事件, 实体,命令
