DDD之事件风暴Event Storming

  |   0 评论   |   0 浏览

什么是事件风暴

官方定义

当我想用一句话总结时，发现【 官方】 已经总结的极好。以下为官方内容的翻译版本。

事件风暴是一种以协作探索复杂业务领域为目标的，灵活的工作坊（workshop）形式的活动。

它有不同的玩法，适用于多种不同的场景：

  1. 发掘现有的健康业务线中最有改进价值的地方
  2. 探索新业务模式的可行性
  3. 设想新的服务，为每个参与方带来最好的正向结果
  4. 设计整洁可维护的事件驱动型（Event-Driven）软件，以支持快速发展的业务

事件风暴的适应性，决定了它允许有不同背景的项目干系人进行复杂的，跨学科的沟通交流，提供了一种跨越信息孤岛和专业界限的新型协作方式。

本质

一套管理复杂软件系统多人协作的步骤和方法，最大可能的让所有人参与表达、专注、思考，促成有效沟通。

事件风暴制定了一些 活动规则「 Liam.wang：实践事件风暴Event Storming 」 ，基于“面对面沟通“和”可视化“两种关键方式，让有不同背景的项目干系人可以进行跨学科、跨部门的沟通交流。关于“面对面沟通“和”可视化“，Jeff Patton 在《用户故事地图》中给出了一副漫画来描述其在共识达成过程中的重要性：

可视化和面对面更容易真正达成一致

事件风暴中的基础概念

事件Event

事件即事实，即在业务领域中那些已经发生的事件就是事实，并可能需要保存下来或者让“别人”响应。

事件是对系统产生了业务上的影响的动作，相对的，如果仅仅是数据查询操作，则只会对系统产生技术上的影响，如CPU上升或者内存上升等。

注意 ：一般查询操作都不会触发事件的产生，所以查询操作不是事件，如点击了查询按钮显示了数据列表，一般情况下不会有类似于： 数据已查询或列表已查询 ，这样的事件。

事件使用正方形橘黄色的便利贴表示，并且是过去式，如：用户已注册（User Registered），激活邮件已发送（ActivationEmail Sended）等。

Domain Event

热点Hotspot（IDEAS, RISKS）

热点表示不确定的点、有风险的点或者需要特别注意的点，一般贴在事件旁边，代表这件事情值得特别关注。

热点使用紫色的便利贴表示，文字描述可以随意点，没有格式要求。

事件与它旁边紫色的热点（图片来自《Introducing Eventstorming》By Alberto Brandolini）

决策命令Command

决策命令产生了事件，可理解为产生事件的动作，与事件一一对应。如 用户已注册（User Registered） 事件对应的决策命令就是注册用户（Register User）。

决策命令用正方形蓝色便利贴表示，在实践中只需要将事件“反过来”就行了。

Command

发起命令的参与者User/Actor

前面的决策命令一定是由某个人或系统来发起的。比如：前面的注册用户这个命令，是由普通用户这个Actor发起的，进而可以联想到可能整个系统中还会有非普通用户，如管理员。

注意：在Big-Picture Event Storming workshop的实践中，不将决策命令贴出来

使用小长方形亮黄色便利贴，结合Command和Event，看起来整体像这样。

图片出自https://zhuanlan.zhihu.com/p/110979132

外部系统External System和规则Policy

Event不一定由前面所说的某个Actor触发Command而产生，也可能是由外部系统或者某种规则自动触发Command而产生。

外部系统使用大长方形的粉红色即时贴表示，规则Policy使用大长方形的紫色即时贴表示。

规则、外部系统、命令的参与者和事件

读模型Read Model

某个Actor做出决策Command的前提是需要看到某些信息，或者说，支撑Actor更容易做出决策命令Command的信息。读模型一般是通过Web页面（UI/UX）来展示更多的信息，以让用户更容易做出决策。

读模型用绿色正方形的即时贴来表示。

图片出自http://apframework.com/2019/12/03/ddd-eventstorming/

聚合Aggregate

某个Actor在某个聚合调用某种Command产生了某个Event。

比如前面的 用户已注册（User Registered） 事件，是由 普通用户（Normal User） 在 注册薄（Register） 上调用 注册用户（Register User） 这个命令而产生。

聚合使用大长方形的黄色即时贴表示。

整体解释

根据下图中的名字将整体串起来解释下。

一个Actor根据看到的Query Model/Information，决定对External System或者Aggregate执行一个Command/Action，进而产生了某种Domain Event。此Domain Event可能触发了某种Policy，此Policy可能又对External System或者Aggregate执行一个Command/Action。此Domain Event也可能会导致Query Model/Information发生变化，从而给Actor提供更多信息以进行其他操作。

此图出自https://virtualddd.com/learning-ddd/ddd-crew-eventstorming-glossary-cheat-sheet

实践形式

事件风暴的灵活性决定了它有多种实践形式，这里主要介绍两种实践形式，更详细的描述见：Liam.wang：实践事件风暴Event Storming

Big-Picture Event Storming

What：一种进行业务全景探索的EventStorming形式

Who：产品经理或者开发Leader/架构师作为主持人，市场分析员、业务人员、财务、UX和其他需要配合的部门代表。总人数控制在8-12人。

When：当一个项目或者产品立项之后，并且业务人员（产品人员）已经基本有了项目/产品的构思。

Why：需要和所有的利益相关人（Stakeholders）一起探索发现业务全景，搭建一个平台让Stakeholder能贡献自己的专业知识，让所有人知道全景/边界、风险点、在此项目中的职责并发现产品/项目的逻辑漏洞。

Big-Pic EventStorming的产出，大量的贴纸（图片来自《Introducing Eventstorming》By Alberto Brandolini）

Design-Level Event Storming

What：一种用于更细节的软件设计的EventStorming形式

Who：开发Leader/架构师作为主持人， 业务人员/产品经理，研发团队所有其他人员：测试、前端/后端、UI等。总人数控制在6-12人左右（为减少沟通成本，研发团队不宜过大）。

When：Big-Pic EventStorming之后，产品经理/业务人员自行进行了进一步业务梳理之后，或者某个业务的上下文需要研发团队介入研发之前。

Why：研发团队所有人都需要知道某个上下文的业务全景，需要学习更多的业务知识，以便开始研发工作；研发团队需要进行业务建模、统一业务语言以及知道业务优先级；业务/产品经理需要补充更多关于实现落地的细节，以便进行User Story的补充和优先级的调整。

两种形式的区别

人员

Big-Picture Event Storming侧重在业务方，重点是所有的干系人（StakeHolders），含研发Leader或者架构师

Design-level Event Storming侧重在研发团队内部，含研发Leader或者架构师

目的

Big-Picture Event Storming侧重在探索业务全景，发现热点（风险点或值得特别关注的点），补充不同领域的知识（如财务、运营等），并让stakeholder了解整个项目以及自己在这个项目中的职责（后期需要配合）。

Design-level Event Storming侧重在向研发团队传播业务知识，并进行业务建模，是研发和业务之间沟通的桥梁。

范围

Big-Picture Event Storming侧重在业务全景

Design-level Event Storming侧重在全景中的某个业务上下文

深入研发组织的问题

虽然大家都强调自己与众不同，但几乎所有的研发组织面临的沟通问题都是类似的

“部门“墙 - Organizational silos

这里的“部门”可以是公司行政规定的部门，也可以是虚拟的组织或者团队。部门是最小职责范围划分的具象化，能让每个人更快的知道自己工作的边界并为公司做出贡献。

凡是企业，几乎必然有部门，凡是研发活动，几乎都会涉及到跨部门协作，凡是跨部门协作，必然会增加沟通成本，这种沟通成本是所有企业研发最大的隐形投入。

每个部门都会认为自己运行的良好，总是对其他部门的工作充满猜想，看不到整体，并且在事情或者项目上总是缺乏真正的对齐，只有自认为的达成一致。

  • 如果相关的stakeholder不了解全貌，会更倾向于拖延而不是积极行动
  • 难以达成共识，特别是跨部门之间，达成的共识更主观，并可能是错误的，会让某些人误以为是故意为之，产生隐形斗争问题
  • 企业架构的混乱。如果架构师不能了解全貌，则无法做出良好的架构决策，也不知道何时应该复用企业已有的技术能力，长期的割裂会造成企业架构的混乱。

图片来自《Introducing Eventstorming》By Alberto Brandolini

自组织团队与决策

如果团队无法理解整个系统，则不可能自组织，如果系统或者需求的决策不是透明的，不是去中心化的，则团队不可能自组织，比如：

  1. 高层集中式决定并突然公布
  2. 与各个stakeholders单独商量修改，并公布给其他人

骄傲的专家

技术人员天然就会有意无意的“鄙视”业务人员 。他们和业务人员沟通时，会不自觉或无意的暗示自己的专业能力，他们喜欢技术能力强的感觉。很多时候这会造成隐形的沟通障碍，因为沟通的一方会不时的陷入自我陶醉，而不是在真正解决业务问题。

换个角度看企业软件研发

> 软件研发就是学习

现实情况是，工程师需要花大量时间来搞明白他们到底要做什么，大多数情况下，他们都是第一次接触某个业务，这是一个学习的过程，而且不是他们擅长的技术领域。

对于工程师来说，业务学习是最容易忽略且不被看重的，甚至还有点不屑。然而忽略业务学习，只关注技术学习，基本就是在浪费资源，是假装在解决一个很可能不会带来任何业务价值的问题，典型的现象是：没有清晰需求的情况下就开始写代码。

学习的过程肯定是累且不舒服的，如果感觉轻松，那很可能是在进行无效的学习（定义和解决一个自以为是的需求）。学习的动力来自于探索的好奇心以及成就感（比如尝试用数据模型来表示问题空间，以便解决比原来的问题更多问题的成就感），业务建模是进行探索式业务学习的一种有效方式。

> 软件研发不仅仅是写代码

不同的人对上面这句话理解不同，从资深工程师的角度来看，写代码只占软件研发的一部分，写代码之前还有设计，还有上线与运维；从业务的角度来看，软件研发就是写代码；从老板的角度来看，特别是不懂技术的老板，软件研发肯定就是写代码。这里的问题是， 如何让相关的人都知道全局，知道除了写代码还有其他哪些工作要做 。

现实情况是，在企业软件中的整个生命周期中， 维护（运维、运营）成本以及软件需求调整/增加的成本才是大头 ，而不是将软件开发出来上线。如果前期需求不清晰，那么就会极大的增加后期需求调整的成本，造成整体成本的增加。如果需求没有和干系人对齐，就不能说需求是清晰的。

图片来自百度百科

写代码以及上线的过程，本身是软件研发比较确定的一部分，所以这部分的提效相对容易。有很多实践来提高写代码过程的效率，比如代码的最佳实践、封装好的类库/接口/服务，招聘更有经验的工程师等。也可以通过DevOps的自动化与规范提高Code -> Build -> Deploy -> Running 这个过程的效率。

> 软件研发就是等待

这是工程师的小秘密，也是合理摸鱼的最佳实践。等待Build完成、等待UT跑完、等待业务把需求明确、等待别人主动讨论问题、等待申请审批通过、等待Leader布置任务等等，更难以注意到的是，在等一件重要的事情的时候，去做无关紧要的事情，让自己忙起来。 可以通过简化流程和尽可能的自动化来减少等待，但不能完全消除（也没有必要，合理的“等待”并不会降低效率）。

> 软件研发就是做决策

业务需求的明确的过程是一个决策的过程，架构师做设计方案的过程是一个决策的过程，制定具体实现方案，技术选型的过程是一个决策的过程，类和方法以及变量的命名也是一个决策过程。基本上一个企业软件的诞生就是一群人做了很多决策的结果。决策的质量决定了企业软件的生命力，足够的输入和讨论决定了决策的质量。与干系人相关却没有达成一致的决策是无效的决策。

事件风暴能解决的问题

正如本文“实践形式”中描述的那样，事件风暴主要有两种形式用于解决不同的问题。总结来看，它打破了“部门墙”，能让所有人了解到业务的全貌，能让技术和业务在同一个游戏平台上解决真正的问题，能让所有人快速学习业务知识。

  • 当软件系统需要进行跨部门的协作与对齐时，能帮助所有stakeholder看到整个系统的全貌、让技术和业务在同一个问题上进行讨论、发现有价值的问题、定义与明确各stakeholder的职责、发现逻辑漏洞、划分系统上下文、统一语言。
  • 当软件系统开始研发之前，能帮助研发团队所有人看到系统的全貌或者一个上下文的全貌、协助进行业务建模，统一语言、非常适合项目研发的kickoff。
  • 当有新人入职时，能帮助新人快速的学习系统的全貌、边界以及统一的语言。

事件风暴不能解决所有问题

软件研发中从来没有所谓的银弹。

不能解决所有的沟通协作问题

不同的沟通形式和方法用于解决不同的问题，事件风暴不可能解决所有沟通问题。如Scrum的站会用于快速同步项目进度、困难，梳理会用于梳理用户故事、评估工作量、同步项目milestone等，回顾会用于团队反思改进、分享最佳实践、表扬激励等。

不能解决Why的问题，更适合解决How的问题

一件事做与不做，取决于长期或者短期带来的价值。如对于企业中产品研发来说，一个产品的做与不做，取决于前期的市场调研与分析，有很多工具和方法论用于解决这个问题，比如SWOT、5 Force analysis、BRD，AWS的逆向工作法等。事件风暴并不能解决“为什么做”的问题，更适合解决“怎么做”的问题。

不适合用做底层技术的讨论

实践证明，事件风暴并不适用于存储系统、API网关、网络通信等底层技术或基础设施的讨论。这些更多需要专业的技术能力，且落地的时候有标准或者最佳实践可以遵循。一般的做法是，架构师或者技术专家进行这些系统的设计，然后跟技术团队沟通并实施，沟通的更多是关于技术人员容易理解的技术上的问题，而不是业务知识。

其他思考

事件特殊在哪里？

  • 普适：事件流以其陈述性且理解使用门槛较低的特点，非常适合不同背景的人通过其进行沟通
  • 准确：事件是已经发生过的、确定的事情且单个定义清楚的事件包含的信息有限，能有效降低对系统描述的歧

软件系统是对现实世界中某些问题的解决方案的实现，所以软件系统表示的是解决方案本身，而不是问题本身。要想解决现实世界中的某些问题，首先要明确问题本身，然后再明确解决方案，最后才是如果实现这个解决方案。

用事件的视角看，问题的解决方案就是一系列的事件按照时间顺序发生，然后问题就得到了解决。对于软件系统，也是如此，可以认为软件系统就是由于某些刺激，而发生了一系列的事件，每一个事件发生后，系统的状态就与事件发生之前不一样了，而软件系统解决问题的目标正是通过不断的响应刺激，产生事件，改变自身状态来达到的。

问题的解决方案（业务）和对解决方案的实现（技术）可以通过事件串起来，他们对事件的理解应该是一致的，否则无法解决问题。

事件风暴与架构活动

架构活动的关键在于定义形式结构与功能（‘形式’和‘功能’的定义来自于《系统架构：复杂系统的产品设计与开发》），而EventStroming是一个通过协作式思考系统中的功能（Event由功能产生），从功能反推系统形式结构的一个活动。

架构活动应该尽可能早的确定所有干系人，识别问题并控制风险，尽可能的消除歧义，确保解决方案能产生真正价值。可以说，EventStorming活动是架构师进行架构活动的辅助工具，同时也提供了独特的视角来确定利益相关者和受益者，需求收集与目标定义，以功能为切入点进行概念的抽象与系统边界的划分，并建立共识。

事件协作式的架构活动

事件风暴与DDD的关系

一般认为这两者的映射是这样的：

  • Big-Picture形式的事件风暴的产出对应战略设计中的领域分析，以划分领域边界和限界上下文。
  • Design-Level形式的事件风暴则继续细化，与DDD的战术设计可以联系起来，可以用来识别聚合根，实体等。

其中统一语言是贯穿始终的！

但，两者可以映射起来并不代表他们之间有什么关系，DDD是以强调业务领域为核心的应对复杂业务系统研发的一套方法，而事件风暴只是探索业务领域的其中一种方式（也可以说是工具）。

事件风暴对应事件建模范式，是以事件为视角来观察真实世界，通过事件引起的领域对象状态迁移来驱动出领域模型，进而影响软件实现的整体架构。与之对应的是对象建模范式，是以对象为视角来观察世界，一切皆为对象。而DDD则不关心使用哪种建模范式，只要以业务为核心，对系统进行建模即可，也就是说，事件和对象都可以是业务模型。

事件风暴与头脑风暴的关系

事件风暴和头脑风暴相似但不相同。它们都是多人一起对一件事情进行思考，都有发散和集中的过程，但有以下不同：

目的和产出不同

  • 头脑风暴是大家需要创意的时候，将大家聚在一起进行idea的碰撞。一般产出是几个较好的点子，但并不知道怎么做。
  • 事件风暴强调体系，是业务建模的过程，将大家聚在一起对业务软件系统进行整体（部分上下文）的探索，风险点发现等。一般产出是整块业务系统的模型，所有人完成了知识的交换与学习。

范围不同

  • 头脑风暴的适用范围更广，几乎任何事情都可以大家一起“脑暴”一下。
  • 事件风暴则是明确的面向业务软件研发。

事件风暴在技术企业中落地的要求

  • 对企业氛围有要求，在开放、协作式、务实且狼性的企业中落地相对容易。开放代表容易接受新的方法论，别人的观点和意见也容易接受；协作式代表一种做事的意识，并不是自己做事，而是大家一起做事；务实代表脚踏实地，不会为了完成任务而去做事件风暴；狼性代表有冲劲有活力，事件风暴本身要求高强度的投入精力和时间，而养老式氛围的企业肯定是排斥的。
  • 对企业的架构能力有要求，或者要求企业必须有架构师岗位。事件风暴本身就与架构活动密不可分，可以贯穿干系人识别，架构目标确认，风险识别，统一语言，需求确认，上下文识别等过程。有架构师作为事件风暴的主持人和发起者，可以做到名正言顺，事半功倍。

参考

原文链接https://zhuanlan.zhihu.com/p/399103071

标题：DDD之事件风暴Event Storming
作者：michael
地址：https://blog.junxworks.cn/articles/2024/02/26/1708918303823.html