【DDD系列-2】风暴出的领域模型
为什么使用DDD
三个问题
1.为什么我们的系统越做越多，越来越庞大，还需要不断的重构？
2.为什么我们的系统业务越来越复杂，服务层的代码越来越多难以维护，不敢维护？
3.为什么一旦业务变化或者数据结构变化，我们的开发量是成倍增加的？
熵增定律
在一个孤立系统里，如果没有外力做功，其总混乱度（熵）会不断增大。
DDD的适应范围
DDD适用于“业务复杂”的且“需要维护和扩展”的系统
数据模型和领域模型的比较
我该如何找出我的服务有哪些领域
三个问题
1.如何找到系统中的 Domain（领域，子域，核心域，通用域，支撑域）
2.如何发现系统中的 Aggregate(聚合)
3.如何划分 Bounded Context(限界上下文)
四种方法
四色建模
时标性对象（moment-interval）
实体对象，人、地点、物（party/place/thing）
角色（role）
描述对象（description）
领域故事讲述
讲述故事（Story telling）
在领域故事Workshop中，要求领域专家使用故事作为示例来解释他完成特定工作流程所采取的步骤。
整理故事蓝图（Story blueprint）
根据领域专家讲述的故事来整理故事架构蓝图，人，地点，物
补充故事细节（Complete the story）
发生的时间，动作，要求等细节补充
重构故事（Reconstruction story）
按时间顺序重构故事
用例分析
事件风暴
事件风暴
什么是事件风暴
事件风暴是一种快速探索复杂业务领域和对领域建模的实践。
无限建模空间 无限即时贴 QA
事件风暴的作用
1.帮助开发人员，业务人员，设计人员，测试等项目参与者对于业务流程有一个统一的认识，这包括关键的流程，核心的业务规则，系统不同模块的使用者。
2.帮助开发人员梳理核心的业务对象，从某种程度上来说就是就是领域对象中的聚合。
事件风暴的流程
准备
参与人员： 组织者 领域专家（运营，产品） 项目成员（产品，技术，测试等愿意参加的项目相关人）
物料： 便利贴 记号笔 足够长的白板 开放空间
建立通用语言：确定统一的名词语义
确定便利贴颜色代表的意义：
关注点：重点关注这类业务的语言和行为
- 比如某些业务动作或行为（事件）是否会触发下一个业务动作，这个动作（事件）的输入和输出是什么？是谁（实体）发出的什么动作（命令），触发了这个动作（事件）
确定产品愿景
寻找领域事件
描述的形似为宾语+动词的过去式
寻找命令和角色
既然有了事件必然有产生事件的对象，这就是命令。
同样的命令也是由对象执行的，这称之为用户
寻找领域模型和聚合
当一个完整的业务流程通过上述方式写完之后，对于每个用户，命令，事件进行组合，我们就能获得聚合了，用事件风暴的描述就是「用户在 XX 聚合对象上执行了 YY 命令，生成了 ZZ 事件」。例如「组织管理员在组织对象上执行了创建组织，生成了组织已创建事件」。即时贴的效果如下图
划分子域和限界上下文
| 子业务域 | 领域模型 | 聚合 | 领域对象 | 领域类型 |
| 组织 | 组织信息 | 组织信息 | 组织 | 聚合根 |
| 绑定用户 | 能力 | |||
| 是否有权限 | 能力 | |||
| ...... | ||||
| 机构信息 | 机构 | 聚合根 | ||
| ...... | ||||
| 用户信息 | 用户 | 聚合根 | ||
| ...... | ||||
| 审计日志 | 日志 | 聚合根 | ||
| 创建日志 | 命令 | |||
| ...... | ||||
| 机构 | 机构信息 | 机构信息 | 机构 | 聚合根 |
| 创建机构 | 命令 | |||
| 租户信息 | 租户 | 聚合根 | ||
| 申请信息 | 申请单 | 聚合根 | ||
服务的拆分与设计
事件风暴常见的问题
1.在寻找领域事件的时候，事件粒度如何控制?
2.对某个事件如果有歧义，该怎么办？
3.一个命令产生了多个连锁事件，该怎么办？
4.领域模型周围的事件过多，导致模型过大，该怎么办？
5.命名是事件的动词吗？
事件的粒度
事件是领域专家关心的业务事件，所以它不能比领域专家关心的业务更细，因为那将毫无意义，也不不能太粗，否则无法确定领域能力。
对某个事件有歧义
应该先前面说的那样，用一个醒目的标记记下来，后面再回过头来充分讨论
一个命令产生多个连锁事件
这个是正常的，一个命令可能会触发一个事件或者多个事件。也有可能一个事件触发了另一个事件，只需要把它们贴在一起即可。
领域模型周围的事件过多
这个时候你们应该警惕了。一个领域模型不应该包含过多的领域事件，因为这会让这个模型变得很大，很复杂。
感觉命令就是事件的动词
很多时候其实就是这样的
成员完全不熟悉业务怎么办？
可以由领域专家（运营，产品）先进行业务大概流程的讲解，就像讲需求流程一样
我该如何落地我的服务
结语
这场仗如果我们不打，就会留给后续的人去打
