DDD建模方法论之【事件风暴法】

DDD建模方法论之【事件风暴法】

前言

在领域驱动设计之初的需求分析阶段，对需求分析的基本思路就是统一语言建模，它是我们的指导思想。落实到具体操作层面，可以采用的具体方法是事件风暴法。

统一语言建模 -> 指导思想。
事件风暴会议 -> 实践方法。

事件风暴

事件风暴（Event Storming）： 一种基于工作坊的DDD实践方法，可以快速发现业务领域中正在发生的事件，指导领域建模及程序开发。

事件：即事实，即在业务领域中那些已经发生的事件就是事实。
风暴：运用头脑风暴会议进行领域分析建模。

特点：

1. 功能很强大：能够在数小时而不是数周内提出完整业务流程的综合模型。

2. 很有吸引力：整个想法是将提出问题并将知道答案的人带到同一房间，并共同建立一个模型。

3. 容易：符号非常简单。

核心概念：

领域事件 Event：

• 正在探索的领域相关的事件。 领域事件的命名需要使用过去式，表示已经发生的事件。如：PatientFollowed 表示患者已随访。

  因为领域事件表示与领域相关的事件，不能简单说随访居民已创建等。命名需要代表深刻的业务领域含义。

• 橙色便签表示。

参与者 Actor：

• 围绕领域事件涉及到的一组人、一个部门、一个团队或一个特定的人。

• 小黄色便签表示。

外部系统 External System：

• 可部署的IT系统。比如事件的触发可能是通过外部第三方系统产生。

• 粉色便签表示。

策略 Policy：

• 根据业务约束和规则自动或手动触发。

• 紫色便签表示。

命令 Command：

• 代表行动、意图。命令在领域事件发生之前，表示事件的触发器。

• 蓝色便签表示。

读模型 Read Model：

• 参与者需要某些信息来做出决策，通过读模型来获取这些信息。

• 绿色便签表示。

聚合 Aggregate：

• 可理解为：一个对象群体、一类对象的总称。

• 大黄色便签表示。

网图 Source: https://www.agilepartner.net/wp-content/uploads/Picture-that-explains-everything.png

实施事件风暴步骤：

这里以用户打车为案例。

此场景只列举出了主要的事件，有错误的地方请指正。

提前准备

• 定会议主持人（协调者/引导者）。主持人可以是产品经理或技术开发，主持人必须使团队保持专注和参与，指导会议进展直到能完成完整的领域模型。

• 邀请相关人员--参与此系统的项目组成员，涉及技术人员、领域专家/业务分析师、产品经理等。

• 预定会议室，准备一个白板，若干颜色的便签纸。

网图 Source: https://leanpub.com/introducing_eventstorming

1. 开一场事件风暴会议

事件风暴会议：

1. 在主持人的指导下，与业务专家开始梳理当前的业务中有哪些领域事件。（即已经发生需要保存下来的那些事实）。

   只有先找到发生的事实，将其标记为领域事件，才能发现这些事实涉及哪些对象，对象之间的结构边界才能得到划分，而划分了边界的对象才可能是DDD中的限界上下文。

2. 针对每一个领域事件，项目组成员围绕它进行业务分析，增加各种命令与事件，进行思考与之相关的资源、外部系统与时间。

领域事件的设计实现

根据“事件风暴”中分析识别的领域事件，在每次完成相应工作以后增加一个对领域事件的发布。相关信息

• 事件名称

• 发布者

• 发布事件

• 相关的数据

2. 按时间线组织这些事件，创建由这些事件组成的合理故事。

3. 加入界面和命令。

事件由命令触发，也可能是外部系统触发，可加入进去。

4. 加入聚合，把命令和事件关联起来。

加入聚合后，这一步可继续完善事件，识别逻辑上漏掉的事件。如支付失败事件，接单失败事件等等。都可以添加上去。

5. 发现限界上下文。识别核心子域。

当识别这些聚合后，就可以根据聚合划分限界上下文（有界上下文）。

每个上下文可对应一个微服务。这个视情况而定，比如评价上下文，只是一个小功能，业务上没有其它扩展的话，可以放在用户上下文中，避免服务拆分过细。

限界上下文

限界上下文确定边界，限界上下文里基础的一些信息或支撑的数据的话就叫支撑域，核心业务模块就叫核心域，通用功能子域就叫通用域。

原则上：一个子域对应一个上下文。

根据上面的拆分：

• 订单是核心业务模块，可识别为核心域。核心域意味着后续公司资源的倾斜。

• 支付：通用的功能，公司其它项目也可调用，企业级复用。可识别为通用域。
  ......

总结

领域建模有很多实践方法，事件风暴只是其中一种，还有原文分析法、四色建模法等等。

在事件风暴会议中：

• 通过建模，可以分析清楚自己的领域模型；

• 通过主题域与支撑域的分析，清楚需要哪些团队提供什么样的接口支持。

应用场景： 事件风暴建模法这种方法比较适用于团队，比如说一帮人在会议室里讨论业务需求，用白板和便签构建领域事件，描述领域对象。最后构建领域模型。

参考资料

1. 彭晨阳：《复杂软件设计之道：领域驱动设计全面解析与实战》

2. 范钢：DDD实战课程

3. https://virtualddd.com/learning-ddd/ddd-crew-eventstorming-glossary-cheat-sheet

4. https://www.agilepartner.net/en/eventstorming-from-big-picture-to-software-design/