DDD的事件风暴

事件⻛暴（Event
Storming）是一种 “自底向上” 的设计方法，先关注具体的业务细节，然后通过归纳、聚合、抽象的方法获得整体层面的认知和设计。

事件⻛暴的发明⼈是 Alberto Brandolini ，它来源于 Gamestorming(游戏风暴)，通过 ⼯作坊（workshop） 的⽅式将领域专家和技术专家召集到⼀起，进⾏共创建模（即它也是一种共创会）。

事件风暴于2013年首次被提出，2015年被ThoughtWorks技术雷达添加到“实验”阶段，2018年被ThoughtWorks技术雷达添加到“采纳”阶段。

事件风暴制定了一些活动规则：基于“面对面沟通“和”可视化“两种关键方式，让有不同背景的项目干系人可以进行跨学科、跨部门的沟通交流。

事件⻛暴是⼀种捕获⾏为需求的⽅法，类似传统软件开发的⽤例分析法。所有⼈员 (领域专家和技术专家) 对业务⾏为进⾏⼀次发散，并最终收敛达到业务的统⼀。所以事件⻛暴可以作为 DDD 建模⼯作坊的⼀种重要的形式，并作为微服务设计的⼀种有效⽅法。

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

1. 产品愿景的主要目的是对产品顶层价值的设计，使产品目标用户、核心价值、差异化竞争点等信息达成一致，避免产品偏离方向。
2. 场景分析是从用户视角出发的，根据业务流程或用户旅程，采用用例和场景分析，探索领域中的典型场景，找出领域事件、实体和命令等领域对象，支撑领域建模。事件风暴参与者要尽可能地遍历所有业务细节，充分发表意见，不要遗漏业务要点。
3. 领域建模时，我们会根据场景分析过程中产生的领域对象，比如命令、事件等之间关系，找出产生命令的实体，分析实体之间的依赖关系组成聚合，为聚合划定限界上下文，建立领域模型以及模型之间的依赖。领域模型利用限界上下文向上可以指导微服务设计，通过聚合向下可以指导聚合根、实体和值对象的设计。
4. 原则上一个领域模型就可以设计为一个微服务，但由于领域建模时只考虑了业务因素，没有考虑微服务落地时的技术、团队以及运行环境等非业务因素，因此在微服务拆分与设计时，我们不能简单地将领域模型作为拆分微服务的唯一标准，它只能作为微服务拆分的一个重要依据。

后面我们分别来看这四个阶段，这里先跳过。

事件风暴前需要提前准备的

参与者

事件风暴采用工作坊的方式，将项目团队和领域专家聚集在一起，通过可视化、高互动的方式一步一步将领域模型设计出来。领域专家是事件风暴中必不可少的核心参与者。很多公司可能并没有这个角色，那我们该寻找什么样的人来担当领域专家呢？

领域专家就是对业务或问题域有深刻见解的主题专家，他们非常了解业务和系统是怎么做的，同时也深刻理解为什么要这样设计。如果没有具体的角色，你可以从业务人员、需求分析人员、产品经理或者在这个领域有多年经验的开发人员里，按照这个标准去选择合适的人选。

领域建模是统一团队语言（DDD中为什么强调统一语言？）的过程，因此项目团队应尽早地参与到领域建模中，这样才能高效建立起团队的通用语言。到了微服务建设时，领域模型也更容易和系统架构保持一致。

材料和场地

在事件风暴开始之前，需要准备以下物料：

• 便利贴：一大堆，最少要四五种不同的颜色；
• 记号笔：人手一支，用于在便利贴上写写写；
• 白板：最好足够长，用来贴便利贴；
• 胶带或者磁扣：以便贴纸随时能更换位置；
• 开放空间：用于小组成员之间的充分讨论。

事件风暴的发明者曾经建议要准备八米长的墙，这样设计就不会受到空间的限制了。当然，这个不是必要条件，看各自的现实条件吧，不要让思维受限就好。