通过本篇文章您可以了解到以下内容:
- Event Storming的由来
- Event Storming具体实施流程
- Event Storming的一个简单示例
- 总结
Event Storming的由来
当我们在谈到Event Storming（事件风暴）时，通常会需要谈起两个概念：DDD（Domain-Driven Design，领域驱动设计）以及微服务。
那么这三者到底有什么关联呢?
无论是Event Storming 还是DDD或者微服务，三者都是为了解决同一个问题，那就是软件系统设计遇到的困难。
微服务作为一种架构设计，通过将巨石应用拆分成若干个微服务，从而把原来内部的耦合性、复杂性进行最大程度的降低，变成可控制化，进而更好的应对业务的快速变化。
DDD是一种软件系统设计和开发的方法论，是一种指导思想，它从理论层面告诉我们如何进行架构的设计。
到这里我们有了目标，微服务架构；我们也有了指导思想，就是DDD ；可是我们具体落地的方案是什么呢? 亦或者说我们实现微服务拆分具体可实施的路径是什么呢?
此时Event Storming登场了，并且给出了完美的答案。
它是将DDD落地到了具体的实践层面，通过workshop形式，将对应的技术人员以及领域专家集中在一起，通过可视化便签纸的方式，以及高互动的交流从而一步一步的挖掘和梳理出业务流程，并形成业务边界和初步的微服务划分，最终形成统一的业务语言。
此外关于Event Storming，我们不得不提到一位大师，他就是Alberto Brandolini，Event Storming就是他发明创造的。
关于Event Storming的定义如下图所示:
（https://www.eventstorming.com）
Event Storming是一种灵活的研讨会形式，用于复杂业务领域的协作探索。
它可以按照不同的形式进行展开，适用于以下多种场景。
- 评估现有业务运行的状况，并发现最有效的提升业务情况的措施
- 探索新业务模式的可行性
- 设想新的服务，最大限度地为各个参与方带来积极正向的成果
- 帮助设计整洁并且可维护的事件驱动软件，以便于支撑快速发展的业务
Event Storming 具体实施流程
在正式开始进行Event Storming之前，我们需要进行一些准备，这里我把它归结为三大类，如下图所示:
需要准备的物理条件大体分为四大类，如下图所示：
- 会议室（较大的开放空间），用于技术人员、领域专家等成员之间的充分讨论。
- 便签纸（各种颜色，用于代表不同意义，例如Domain Event、Command等）。
- 笔 （最好每个人一支），用于在便签纸上书写。
- 白板 用于贴便签纸。
在物理条件具备以后，接下来就是需要邀请相关人员进行参与，整体可以分为三类人员：
- 组织者，熟悉整个Event storming的流程，保证整个过程大家顺利完成。
- 领域专家，对业务流程精通的人，在整个Event storming过程中负责澄清业务上的某些概念，并且查看是否有遗漏的事件。
- 项目成员，该项目的成员，角色包括开发人员、架构师，通过Event storming快速让整个团队熟悉了解整个项目的业务流程。
在物理条件准备以及人员邀请完成后，我们还需要对参与此次项目的人员进行关于Event Storming的概念和组织方式的介绍。因为在整个Event Storming过程中会使用到不同颜色的便签纸，不同颜色代表的内容含义不同。由于参与整个workshop的成员不一定很熟悉具体含义，此时可以由组织者进行具体的介绍和解释，每种不同颜色的便签纸怎么去使用，如下图所示:
DOMAIN EVENT
一般情况使用橘色便签纸表示，代表业务流程中已经发生的事件，此处需要注意的是需要用过去式表示。例如用户已注册（User Registered）。
COMMAND
一般情况使用蓝色便签纸表示，代表产生某一事件的动作。即在之前产生的领域事件中加入Command的概念。其中Command代表的是意图、动作。
VIEW
一般情况使用绿色便签纸表示，代表用户与之交互以在系统中执行任务的视图。
POLICY
一般情况使用紫色便签纸表示，代表某种规则。例如在支付过程中，需要输入密码，而多次输入错误，就会触发账户冻结操作。多次输入错误，就是我们的Policy，而账户冻结就是被Policy触发的新的领域事件。
ACTOR
一般情况使用黄色便签纸表示，代表一类特定的用户。
AGGREGATE
一般情况使用尺寸比较大的黄色便签纸表示，代表概念相同的command和domain event聚合在一起。可以认为Aggregate就是微服务的雏形。
EXTERNAL SYSTEM
**一般情况使用粉色便签纸表示，这个相对好理解，代表的是第三方外部系统。
TROUBLE SPOTS
一般情况使用红色便签纸表示，遇到的麻烦，或者问题。
至此前期准备都已经完成，接下来让我们看下整个流程是怎样的。
首先是领域事件的收集。
这些事件是要以过去式的方式进行表达，是因为从通俗语言的角度来理解，事件本质上就是已发生的事实。
这里需要注意的一点是事件是有相对顺序的，我们可以把有相对顺序关系的事件放在同一行并贴在之前准备好的白板上。此外由于每一个人都可以进行事件的书写，此处不必担心彼此书写重复，后续可以进行合并，缺失可以由领域专家进行指正，补充。
另外一点，由于参与人员有时并不一定十分熟悉整个流程，可以由组织者书写第一个事件。
在收集完所有领域事件之后，我们可以在此基础上进一步探索，并加入Command以及Actor角色。即某个Actor执行了某个Command产生了对应的Domain event。
此时在融入Domain event、Command、Actor后，可能会产生更多思考，例如某些command是否在特定的条件下所触发，而这种逻辑就是Policy。
接下来我们将相同Command以及Domain event进行归类，代表的就是Aggregate，此时我们用尺寸比较大的黄色便签纸进行表示。
最后通过Aggregate我们就可以相对容易的划分子域和限界上下文了。
Event Storming的一个简单示例
通过上一章节的介绍，相信大家对Event Storming中的概念，以及实施流程有了较为清晰的理解。可能有些概念较为晦涩抽象，同时Event Storming本身是以workshop动手实践为主的形式，所以为了更好的加深我们对整个流程的理解和认知，接下来会结合一个例子，再次来回顾下整个流程。
我们以一个普通用户注册的业务进行说明:
第一步：定义Event
我们需要寻找Domain event，在上面描述的场景中，用户注册就是一个典型的Event，需要注意的是我们需要使用过去式的方式，所以对应的这个Event就是“用户已注册”。
第二步：寻找Event对应的Command
Command是代表某一个事件对应的动作，在上一步骤中描述的Event“用户已注册”，我们可以确定相对应的 Command是“注册用户”。
第三步：定义Actor
Command是由谁发起执行的呢? 如果我们接受任何普通用户进行注册申请，那么在这个Event Storming的流程里，普通用户就是Actor。即一个普通用户通过注册用户的这种动作，产生了一个与之对应的用户已注册的事件。
第四步，定义Policy
在第一到第三步的过程中，可能会遇到某些逻辑下才触发的Command，比如用户注册成功以后，系统推送短信或者邮件提醒。这种逻辑称之为前面介绍过的Policy。
以上的第一步到第四步我们可以进行重复进行，直至整个业务流程都梳理完毕。然后将command和domain event归类聚合在一起，就形成了如下的Aggregate，微服务的雏形就初步形成了。
这是一个非常简单的示例以介绍Event、Command、Actor等的概念和大致Event Storming的流程，但是在实际工作过程中，往往业务场景会非常复杂，企业级应用涉及到的事件会很多，我们需要针对每个事件进行相关联的分析和梳理以支撑后续的微服务设计的进一步细化。
总结
要实现微服务架构设计，我们可以使用DDD作为思想指导，并使用Event Storming进行具体实践落地。在本篇文章中依次向大家介绍了Event Storming的由来、定义、前期准备要求，以及整个Event Storming实践流程。
Event Storming之后，我们就需要结合Event Storming的产出，即微服务的雏形，进行下一步操作— Boris。什么是Boris，整个实施的流程又是怎样的? 我在下期的文章中会继续和大家进行交流分享，敬请期待!
参考链接:
1.https://www.eventstorming.com
2.https://tanzu.vmware.com/deve...
作者简介
李刚，VMware 大中华区应用现代化部门高级系统架构师，资深企业级软件开发和软件系统架构师。Spring Cloud开源社区项目贡献者、Netflix开源社区贡献者。近几年，参与并主导了许多大型企业客户的应用现代化数字转型项目，涉及物流、制造、金融等诸多领域。特别对微服务实现方法、现代化应用架构设计、云原生实施落地、开源软件技术等方面有着丰富经验。
来源｜公众号：VMwareTanzu云原生