事件风暴

本文译自事件风暴提出编写文件：http://ziobrando.blogspot.com/2013/11/introducing-event-storming.html

免责声明：这是关于 EventStorming 的开创性文章。这是一切开始的地方，所以我认为保留原件是相关的。同时， 自从我写这篇文章以来，EventStorming 已经发展了很多，这个页面描述的格式不再是我最喜欢的。事实上，没有单一的 EventStorming 格式，该工具证明了自己的多功能性和强大功能，以至于我完善了一些不同的方法。我还不得不开始 写一本关于它的书，它正在慢慢地完成。到今天为止，理解 EventStorming 潜力的更好切入点可能是我稍后的演示文稿50.000 个橙色便签（也可以在视频中找到）) 或阅读本书的第一章，这是免费的。我们还在开发EventStorming.com网站的新版本，该网站应该组织指向许多从业者发布的有关 EventStorming 的有趣内容的指针。 在过去的几个月里，我花了一些时间来试验这个奇怪的东西。一开始就像“哎哟我没时间画精确的 UML 图，让我们来做这个吧”然后变成了我在 2012 年意大利敏捷日上提出的基于事件的建模研讨会，后来我有机会做更多的实验在 Vaughn Vernon 的 IDDD 之旅期间在比利时和波兰，我收集了非常宝贵的反馈和见解。我设法找到了一个更酷的名字 - EventStorming - 就在 2013 年夏天整个事情爆发之前。虽然我意识到它有很多价值，但其他从业者（Mathias Verraes、Tom Janssen、Marco Heimeshoff、Yves Reynhout、Tomas Jaskula，Alessandro Colla、Andrea Balducci、Jef Claes，仅举几例）开始探索和使用这种格式并取得了惊人的结果，这让我得出结论，这不仅仅是“另一种研讨会格式”。

什么是事件风暴

EventStorming 是一种研讨会形式，用于快速探索复杂的业务领域。 它很强大：它使我和许多从业者能够在数小时而不是数周内提出完整业务流程的综合模型。 它很吸引人：整个想法是将提出问题的人和知道答案的人带到同一个房间，并一起构建模型。 它是高效的：生成的模型与领域驱动设计实现风格（特别适合事件溯源方法）完全一致，并允许快速确定上下文和聚合边界。 这很容易: 符号非常简单。没有复杂的 UML 可能会使参与者远离讨论的核心。 很有趣：我一直很开心领导研讨会，人们充满活力，交付的成果超出了他们的预期。正确的问题出现了，气氛也是正确的。

它是如何工作的

以下是基本步骤：

• 邀请合适的人 参加研讨会。理想情况下，您需要一个可容纳 6..8 人的大型会议室，由知道要问的问题（并且好奇地想听答案）的人和知道答案的人组成。
• 提供无限的造型空间。复杂的问题往往没有得到正确分析，因为没有足够的可用空间来查看 问题。你的问题比你的白板还大，那又怎样？我的解决方案是 使用任何可用的工具（我最喜欢的工具是宜家纸卷）来破解建模空间，以摆脱空间限制。
• 从领域事件开始探索领域。一个域事件是有意义的事在发生域。它可以很容易地翻译成软件，但这里的真正价值在于它可以从非技术人员那里快速掌握。一个事件可能是另一个事件的追随者的前身。根据时间线将它们全部放置在您的建模表面上（惯例是为此目的使用橙色便签）。
• 探索领域事件的起源。某些事件是用户操作的直接结果 —> 使用蓝色 便签将其表示为命令。其他是外部系统中发生的事情或时间流逝的结果，我们将为它们使用紫色 便签。在其他一些情况下，我们会有一些其他事件的直接结果的事件。我们将简单地将这两个事件放在一起。
• 寻找聚合。我们不是从代码开始定义聚合，而是采用由外向内的方法：聚合是系统的一部分，它接收命令并决定是否执行它们，从而产生域事件。

奖金目标

这些是原始 EventStorming 格式的基本步骤。但是，如果讨论变得热烈，您可能会在此过程中发现一些奖励目标。这是一个可能的奖励目标列表，值得考虑作为标准路线的有益绕道。

• 探索子域：一些领域专家会在某个领域展示更多的专业知识，而将领域的其他部分留给其他人。如果您过去看过我的演讲，不同的责任领域可以很好地映射到不同的子域或猪肉部分。
• 探索有界上下文：在讨论过程中，可能会出现一些冲突区域。具有 DDD 思维方式的开发人员和协调员会发现对术语的不同解释，作为围绕含义进行讨论的触发因素。这可能是在您的域中共存的多个一致模型之间划清界限的好时机。
• 绘制用户角色：在谈论命令时，对话往往会转向发出命令的上下文和触发操作的人的目标。这是有价值的信息，不要吹！您可以扩展符号以包含小的黄色便笺作为角色。
• 草图关键验收测试：如果讨论开始围绕极端案例或模棱两可的场景展开，没有比定义清晰的验收测试更好的方法来消除歧义。并非所有场景都需要以这种方式记录（我的意思是不在本次研讨会中，主要是出于时间原因）但如果它们在某些领域是决胜局，那么现在没有理由不捕捉新兴知识。
• Sketching Key Read Model Artefacts：对于某些场景，用户所看到的远比系统所做的重要得多。如果屏幕、表格或图形对给定用户特别有价值，只需将其草绘在便笺中并将其放置在与其关联的命令附近。

以下是迄今为止所有可能的研讨会步骤的概述：

可以在这里看到质量更好的图像

把所有东西放在一起是很多东西。请记住，研讨会的目标是在尽可能短的时间内尽可能多地学习。我们邀请了关键人物参加研讨会，我们不想浪费他们的时间。

所以，当谈到这些奖励目标时，准备好以最有效的方式利用时间：你得到一个有价值的提示，只需勾勒它并将相应的粘性放在热点中。不要推动模型完整性的讨论：模型将是巨大的，完成它可能没有什么价值，甚至对某些参与者来说听起来很可怕。

接受不完整会让研讨会不那么无聊，而且更有成果。

选择正确的格式

正如您所注意到的，研讨会没有单一的形式。事实上，第一步或多或少是相同的，但形式可能会根据参与者的角色和项目范围而有所不同。

最小范围

我发现即使在停止领域事件时，结果也非常有价值，即我们在我的公司进行了一个 EventStorming 会议，探索我们正在运行的培训课程的业务流程。参与者不是开发人员，因此目标只是通过提出正确的问题来理解系统。我们在几个小时内就完成了。在研讨会结束时，每个新员工都清楚地知道我们公司应该做什么。

（在这个场景中，我们使用了稍微不同的符号，这对参与者更有意义：橙色 —> 事件，紫色 —> 外部系统，蓝色 —> 外部组织或社区，绿色 —> 人工制品）。

在探索软件开发时，结果更加强大。聚合、命令和领域事件，都很好地映射到软件工件中。您可能会举办研讨会以真正快速地掌握全局，并提供一个物理空间，可以围绕流程进行讨论。

将模型转化为代码

DDD 从业者喜欢这种方法，不仅因为它很有趣，而且因为生成的模型更接近他们需要的模型：这不是没有数据模型。生成的模型是完全行为的：没有底层数据模型限制实现的本质。如果您面向命令-查询职责分离，那么在尝试研讨会之后，您可能会遇到为我提供啤酒的紧迫性。

您还可以几乎立即开始编码，并在很短的时间内验证您在代码中的探索结果。这是最高效的团队所做的，基于讨论的发现与面向领域驱动的实现相结合可以带来巨大的改进。

您基本上会更快地实施正确的事情。

我如何开始做 EVENTSTORMING？

运行一个实验并没有那么困难。所有你需要的是：

• 一个合适的房间，安静且足够大以容纳建模表面（如果天气允许，也可以选择户外建模，但风可能是主要障碍）；
• 一个可写的表面，很可能是宜家纸卷（代号 Måla，您可以在儿童区找到它）。
• 大量不同口味的便签（基本套装是淡黄色长方形便签，外加橙色、蓝色和紫色方形便签）；
• 工作标记，理想情况下每个参与者一个加上备份；
• 一些美纹纸胶带，以防万一；
• 合适的人。
• 一个促进者。

在让你的达斯维达式老板参与进来之前，你可能想在沙箱中对执行进行原型设计（一些用户组非常适合，他们喜欢实验）。您可能还想加入不断壮大的从业者和实验者社区。

或者，您可能想聘请一名协调员，为期一两天，在您的公司举办研讨会，同时提供有关研讨会本身和进一步可能步骤的指导。