DDD

领域驱动设计，拆分微服务的一种方法论

4大作用

统一思想

统一项目各方如业务、产品、开发对问题的认知，领域模型提出阶段，各方参与，头脑风暴

明确分工

明确定义领域模型

反映变化

需求不断变化，领域模型真实反映变化

边界分离

领域模型与数据模型分离

概念

领域

DDD最大概念，确定边界范围，分为核心域（核心业务逻辑）、通用域（公共业务逻辑）、支撑域（基础第三方业务逻辑）

界限上下文

确定领域边界，bcm.das

聚合根

一个根实体，包含多个聚合，拥有唯一标识，协调每个聚合，外部只能根据聚合根的唯一标识进行访问，单板切换关系

聚合

将实体、值对象组织起来的整体，是数据持久化的基本单元，单个聚合内保证事务一致性，切换关系+单板

实体

业务对象，拥有唯一标识、业务属性、行为、业务逻辑

值对象

属性集合，无业务逻辑

4种模型

失血模型

只有get、set方法，业务行为由服务类完成

贫血模型

聚合业务领域行为，不关注数据持久化，三层架构

充血模型

负责数据持久化

胀血模型

不需要service，所有业务逻辑、数据存储放到一个类中，初学者

建模方法

用例分析法

1、获取用例，提取领域规则描述

2、收集实体，定义实体

3、添加关联，两个实体间用动词关联

4、添加属性，定义属性

5、模型精化，使用UML的泛化、组合表达模型关系，划分子领域

4色建模法

1、角色

2、地点，场景

3、使用东西

4、事情

事件风暴

类似头脑风暴，谁在何时，基于什么干了什么，产生了什么，影响了什么

1、根据具体业务，找出过程中发生行为的实体、值对象

2、选出聚合根，根据独立生命周期、全局唯一ID，是否可以修改或创建其他对象

3、找出聚合根关联的聚合，聚合关联的实体、值对象，根据业务单一职责、高内聚原则

4、画出对象引用模型、依赖关系模型，根据聚合根、聚合、实体、值对象

5、多个聚合根据业务语义划分到一个上下文界面，即微服务

架构分层

Application 包含事件注册、业务逻辑

Domain 聚合、实体、值对象

InfraStructure 基础设施封装、数据库访问

与微服务结合

微服务区别于系统，是一组相对较小且独立功能单元，是用户感知最小功能集

DDD中具有边界的最小原子是聚合，聚合与聚合之间只通过聚合根进行关联，移动成本低，方便微服务重构

DDD拆分

事件风暴

领域划分

实体聚合

上下文边界确定

与MVC区别

主要区别在Service层

MVC Service实现业务逻辑，BO保存业务对象，属于贫血模型

DDD Service实现少量业务逻辑，DO包含聚合根、聚合、实体、值对象，另外有领域行为、动作、属性、依赖关系，属于充血模型

概念

实体

拥有唯一标识的核心领域对象，包括业务逻辑，是操作行为载体

值对象

依附于实体存在，打包实体属性，如用户的省市区属性打包

聚合

多个实体一起协同工作，是数据持久化的基本单元，同一个聚合内保证事务一致性

聚合根

也叫根实体，聚合管理者，表示聚合入口

领域服务

有些领域的操作是一些动词，声明成一个服务，为领域提供相应的功能

领域事件

用户触发的事件，如充值成功