image-20210421104208638

什么是EventStorming（事件风暴）

EventStorming（事件风暴）是一种讨论会模式，旨在协同创建一个复杂的业务流程的模型。

现在，当很多人谈到DDD都会同时谈到EventStorming，甚至有人误认为这两个名词本身指代的就是同一个概念。

但其实这是两个完全独立的工具。

DDD是一套基于领域的分析和建模方法，而EventStorming则是一套Workshop（可以理解成一个类似于头脑风暴的工作坊）方法。DDD出现要比EventStorming早了10多年，而EventStorming的设计虽然参考了DDD的部分内容，但是并不是只为了DDD而设计的，是一套独立的通过协作基于事件还原系统全貌，从而快速分析复杂业务领域，完成领域建模的方法。

下图是对于EventStorming的一个清晰完整的概括。其完整的阐释了从系统外部与用户的交互，到系统内部的事件的传递，以及通过事件影响读模型从而给予用户动作的响应，从而完成一个完整闭环的过程。

img

EventStorming（事件风暴）、DDD（领域驱动技术）还有Microservice（微服务）有什么关系？

image-20210521170851052

什么时候需要使用EventStorming（事件风暴）？

  1. 项目开始时，需求分析和知识共享
  2. 当开始一个较新的功能或应用的开发时

EventStorming（事件风暴）的优点？

  • 这是一种有很强参与感的方法，每个人都拿着一叠便利贴和马克笔，随时可以加入学习和设计的讨论中，业务人员和开发人员在平等的基础上共同学习，我们所使用的语言都是被大家所理解的，而不是讨论业务人员无法理解的数据库，对象，类，等等概念；
  • 它令每个人都聚焦于事件业务流程，而不是类和数据库；
  • 这是一种高度视觉化的方法，消除了实验过程中的代码，让每个人平等的参与到设计过程中；
  • 实施起来非常快，投入成本很低，只需花几个小时，而不用数周就差不多可以通过头脑风暴得出粗略的核心领域模型；
  • 团队成员无一例外地会取得对业务理解的突破；
  • 每个人都能学习到业务知识，无论是业务还是开发人员都会带着对现有模型的新鲜且清晰的理解离开讨论。在许多项目中，一部分甚至大多数项目成员根本不了解他们的工作内容，直到代码出现问题，才发现为时已晚。快速产出的模型能帮助每个人消除误解，朝着统一的方向和目标前进；
  • 细粒度的事件为开发人员后续的研发提供了模型设计。

如何使用？

事件风暴将系统拆分为不同的元素，用不同颜色的即时贴表示，请参考下图对于不同颜色即时贴的解释:

image-20210521171236776

  • 事件(Event): 事件风暴中的核心概念，它代表了某一个「业务行为」，描述的形似为宾语+动词的过去式。例如: 「订单被提交」，「账户被锁定」，「商品已被发出」。使用橙色的即时贴表示。

  • 命令(Command): 既然有了事件必然有产生事件的对象，这就是命令。命令可以理解为是一个动作，执行了动作之后就会产生相应的事件。典型的动作描述可以是: 「取消订单」，「结账」等。使用深蓝色的即时贴表示。

  • 用户(User 或 Actor): 同样的命令也是由对象执行的，这称之为用户。这里的用户一般是指自然人，例如一个电子购物网站的顾客。

  • 聚合(Aggregate): 当一个完整的业务流程通过上述方式写完之后，对于每个用户，命令，事件进行组合，我们就能获得聚合了，用事件风暴的描述就是「用户在 XX 聚合对象上执行了 YY 命令，生成了 ZZ 事件」。例如「顾客在购物车对象上执行了结账命令，生成了购物车结算事件」。

  • 规则(Policy): 当产生事件时，需要进行某些业务相关的规则校验，例如订单提交后需要检查库存是否充足，客户的支付交易是否成功等，诸如此类的业务规则可以使用粉色的即时贴表示。

  • 读模型(Read Model) 与页面布局(Screen Layout): 事件产生后的另一个结果往往是呈现在用户面前的系统界面，在这里我们使用页面布局进行展示。这部分的工作一般由 UX 与业务人员完成，展现他们所需要的用户界面。同时页面布局上会展现用户所关心的数据，例如，当用户执行「结账」的命令之后，生成了「购物车结算」事件，此时呈现在用户面前的应该是商品明细信息和总金额。这样的数据我们使用读模型表示。

  • 外部系统(System): 事件并不一定由命令产生，也可能由一个外部系统产生，例如一个第三方的支付系统会调用由你系统提供的回调接口，确认客户支付成功，由此产生一个「费用已支付」的事件。

  • 问题(Question) 与假设(Assumption): 在讨论过程中各个参与人员可能会发生分歧，例如对于事件的定义，或是由哪个用户执行，或者是具体的规则是什么。此时如果无法在规定的 time box 之内达成统一意见(一般为 5 分钟)，可以将问题写在红色的即时贴上，作为问题，或是对某种情况的假设记录下来。

所以，EventStorm到底帮我们解决了什么问题？

提供一种成型的方法和特定的模式，帮助开发人员，业务人员，UX，测试人员等项目参与者，对于业务流程有一个统一的认识，这包括关键的流程，核心的业务规则，系统不同模块的使用者。

另外，帮助开发人员梳理核心的业务对象。说白话对应到DDD中，最重要的就是以下两点。

  1. 发现Aggregate(聚合)
  2. 发现Bounded Context(有界上下文)