《DDD实战》读书笔记六（事件风暴）

概述

• 事件风暴是一项团队活动，领域专家与项目团队通过头脑风暴的形式，罗列出领域中所有的领域事件，整合之后形成最终的领域事件集合，然后对每一个事件，标注出导致该事件的命令，再为每一个事件标注出命令发起方的角色。
• 命令可以是用户发起，也可以是第三方系统调用或定时器触发等，最后对事件进行分类，整理出实体、聚合、聚合根及限界上下文。

准备

参与者

• 事件风暴采用工作坊的方式，将项目团队和领域专家聚集在一起，通过可视化、高互动的方式一步一步将领域模型设计出来。
• 参与者包括领域专家，DDD专家，架构师，产品经理，项目经理，开发人员和测试人员等项目团队成员。

准备材料

• 事件风暴参与者会将自己的想法和意见写在即时贴上，并将贴纸贴在墙上的合适位置，这个过程称为“刷墙”。所以需要即时贴、水笔、胶带或磁扣。
• 在这个过程中，用不同的颜色贴纸区分领域行为，我们用蓝色表示命令，绿色表示实体，橙色表示领域事件，黄色表示补充信息。
• 补充信息用来说明注意事项，比如外部依赖等。
  

场地

• 只需要一堵足够长的墙和足够大的控件就可以，墙是用来贴纸的，大空间可以让人四处走动，方便合作。
• 事件风暴的发明者曾经建议准备8米长的墙，这个是非必要条件，根据实际条件即可。

分析关注点

• 在领域建模的过程中，我们需要重点关注这类业务语言和行为。如：某些业务动作或行为（事件）是否触发下一个业务动作，这个动作（事件）的输入和输出是什么？是谁（实体）发出的什么动作（命令），触发这个动作（事件）。从这些暗藏的词汇中分析出领域模型的事件、命令或实体等领域对象。

如何构建领域模型

• 领域建模过程主要包括产品愿景、业务场景分析、领域建模和微服务拆分与设计这几个重要阶段。

产品愿景

• 产品愿景的主要目的是对产品顶层价值的设计，是产品目标用户、核心价值、差异化竞争点等信息达成一致，避免产品偏离方向。
• 建模之前，项目团队需要考虑两点：
  – 用户中台到底能做什么
  – 它的业务范围、目标用户、核心价值和愿景，与其他同类产品的差异和优势在哪里。
• 参与者对每一个发表意见，用水笔写在贴纸上，写完贴在黄色贴纸位置。
  

业务场景分析

• 场景分析是从用户视角出发，根据业务流程或用户旅程，采用用例和场景分析，探索领域中的典型场景，找出领域事件、实体和命令等领域对象，支撑领域建模。事件风暴参与者要尽可能遍历所有业务细节，充分发表意见，不要遗漏业务要点。
• 场景分析时会产生很多命令和领域事件。蓝色表示命令，橙色表示领域事件，黄色表示补充信息。
  

领域建模

• 领域建模时，根据场景分析中产生的领域对象，如命令、事件等之间的关系，找出产生命令的实体，分析实体间的依赖关系组成聚合，为聚合划定限界上下文，建立领域模型及模型间依赖。
• 领域模型利用限界上下文向上可以指导微服务设计，通过聚合向下可以指导聚合根、实体和值对象的设计。

具体可以分为以下三步

• 从命令和事件中提取产生这些行为的实体。用绿色表示实体。
  

• 根据聚合根的管理性质从七个实体中找出聚合根

• 划定限界上下文，根据上下文语义将聚合归类。
  

• 领域建模过程中产生的领域对象太多，可以借助表格记录。
  

微服务拆分与设计

• 原则上一个领域模型可以设计为一个微服务，但是由于领域建模只考虑业务因素，没考虑微服务落地的技术、团队及运行环境等非业务因素。因此在微服务拆分与设计时，不能简单的将领域模型作为拆分微服务的唯一标准，只能作为微服务拆分的重要依据。
• 微服务设计还需要考虑服务的粒度、分层、边界划分、依赖关系和集成关系，除考虑业务单一职责外，还要考虑将敏度与稳态业务的分离、非功能性需求（如弹性伸缩要求、安全性等要求）、团队组织和沟通效率、软件包大小及技术异构等非业务因素。

总结

• 事件风暴是一种不同于传统需求分析和系统设计的方法，一般一个中型规模的项目，建模时间大概两周左右，如果建模过程中，团队成员都参与，在项目开发前就建立共同语言，对后续的设计开发有帮助，时间成本可以视情况降低。