活动风暴是一种快速探索复杂业务领域的研讨会形式。研讨会重点关注在业务流程或业务应用程序的上下文中生成的域事件。域事件是在域中发生的有意义的事情。研讨会侧重于产品所有者，领域专家和开发人员之间的沟通。

事件风暴方法由Alberto Brandolini在介绍EventStorming中介绍和公布。这种方法在领域驱动设计社区中被认为是一种快速捕获解决方案设计并提高团队对设计的理解的技术。 EventStorming的这种变体包含对事件驱动架构设计有用的改进和扩展。扩展方法通过添加有关未来可能事件的预测性见解，增加了识别和捕获价值的洞察力。通过使用数据科学分析，数据模型，人工智能（AI）或机器学习生成预测性见解。

对于实际研讨会的详细输出，该研讨会应用事件风暴和洞察力冲击全球集装箱运输，请参阅集装箱运输分析。

举办活动和洞察力风暴研讨会

在您举办活动风暴研讨会之前，请完成企业设计思维研讨会，您可以在其中开发人物角色和移情地图，并定义业务难点和目标。事件风暴研讨会为流程的每个步骤中发生的事件，微服务的自然环境以及指导系统操作的预测性见解添加了更具体的设计。

通过这种方法，包含业务所有者和利益相关者的团队可以为解决方案定义最小可行产品（MVP）。最终的设计被组织为松散耦合的微服务的集合，这些微服务通过事件驱动的体系结构和一个或多个事件主干链接。这种设计风格可以部署到多云执行环境中，并允许扩展和敏捷部署。

完成这些任务以准备活动风暴研讨会：

• 找一个足够容纳至少6到8人的房间，并且有足够的墙面空间来张贴大纸张。您需要墙面空间来定义模型。
• 收集不同颜色的粘滞便笺，黑色标记或笔，以及蓝色画家的胶带。
• 不鼓励在会议期间使用开放式笔记本电脑。
• 限制椅子的数量，以便团队保持专注和连接以及对话流程。

概念

在活动风暴研讨会期间使用的许多概念都是在域驱动设计方法中定义的。 下图显示了分析过程中使用的元素。 第一个图显示了该过程中使用的初始概念集。

域事件也称为业务事件。 事件是在特定时间在系统中发生的操作。

事件风暴过程的第一步包括以下操作：

• 识别域中的所有相关事件以及您正在分析的特定过程
• 在便利贴上写下每个事件的简短描述
• 在时间轴上按顺序放置所有事件便签

编写事件描述的行为通常会导致需要稍后解决的问题或有关需要记录的定义的讨论，以确保每个人都同意基本的域概念。

域事件的时间线是事件风暴过程中第一步的关键输出。 时间表使每个人都能够了解事件何时发生在彼此之间。 您仍然需要采用这种初始理解水平并将其转向实施。 在进行该步骤时，请扩展您的思路以包含命令的概念，该命令是启动触发事件的处理的操作。 作为理解命令角色的一部分，您想知道谁启动命令（actor）以及允许命令运行所需的信息。 此图显示了这些分析元素如何链接在一起：

• Actor通过用户界面消费数据，并通过发出命令与系统交互。 AI代理也可以替换演员。
• 命令是用户决策或策略的结果。它们作用于CQRS模式中的Read模型的相关数据。
• 策略是在事件发生后发生的反应逻辑。在此示例中，策略由浅紫色便签指示。策略会触发其他命令。策略总是以“when ...”开头。策略可以是人类遵循的手动步骤，例如文档化的过程或指导，或者它们可以是自动化的。应用敏捷业务规则开发方法时，策略将映射到决策模型表示法中的决策。
• 外部系统产生事件。
• 数据可以在用户界面中呈现给用户或由系统修改。

事件可以通过命令或外部系统创建，包括物联网（IoT）设备。事件可以通过处理其他事件或经过一段时间来触发。当事件重复或按计划定期发生时，在该事件的便签的角落绘制时钟或日历图标。

当您识别事件并将它们放入时间线时，您可能会发现独立的后续事件彼此不直接耦合并且代表系统的不同视角，但这些事件发生在重叠的时间段内。您可以将这些并行事件流放入单独的泳道中，这些泳道由水平蓝色画家的磁带识别。

当您将事件组织到时间线中时（可能使用泳道），您可以识别关键事件。关键事件表明域中的主要变化，并且经常形成系统的一个阶段与另一个阶段之间的边界。它们通常在域驱动设计术语中分离，或者是有界的上下文。关键事件由垂直蓝色画家的磁带识别，穿过所有泳道。

此示例显示已完成事件时间轴的一部分，其中包含关键事件和泳道：

举办研讨会

研讨会的目标是更好地了解未来应用程序要解决的业务问题。该方法还可以应用于找到瓶颈或应用程序中的其他问题的解决方案。该研讨会通过在业务流程生命周期内构建域事件的时间表，帮助团队了解解决方案的总体情况。

避免在研讨会期间记录处理步骤。您没有尝试指定特定的实现。相反，在研讨会的初始阶段，重点是识别和排序解决方案中发生的事件。事件时间表是整个步骤的有用表示。它传达必须发生的事情，但允许许多可能的实现方法。

第1步：域事件发现

首先在粘滞便笺上写下每个域事件，并用过去时的几个单词和一个动词。在此示例中，使用橙色便签。描述发生的事情。首先，通过让每个域专家生成单独的域事件列表来“暴乱”事件。最初，您可能不需要将事件放在有序时间轴上。这些事件必须以对域专家和业务利益相关者有意义的方式措辞。您正在解释业务术语中发生的事情，而不是系统实施中发生的事情。

您无需描述域中的所有事件，但必须涵盖您有兴趣从头到尾探索的过程。确保您识别开始和结束事件，并将它们放在墙的开头和结尾的时间轴上。将您在这两个端点之间确定的其他事件放在团队可以按顺序达成一致的最接近的近似值中。不要担心重叠，因为您稍后会解决它们。

第2步：讲述故事

在这一步中，您将通过讨论如何将事件与角色相关联来重述故事。团队成员采用域中角色的视角，并询问哪些事件跟随哪些事件。这个团队成员通常是推动者，但其他人也可以扮演这个角色。

例如，辅导员可以采用想要将小部件发送给客户的制造商的观点。从该角色的互动开始，然后问：“接下来会发生什么？”拿起并重新排列团队风暴的事件。如果您发现重复的事件，请将重复的事件从墙上取下。如果事件的顺序错误，请将它们按正确的顺序移动。

如果某些部分不清楚，请使用不同颜色的便签添加问题或评论。在此示例中，使用红色便签。这些粘滞便笺表明团队需要跟进并在以后澄清问题。同样，使用这段时间来记录定义粘滞便笺的假设。在您浏览故事时，步骤2也是重新定义事件的好时机。有时，您需要通过将动词置于过去时或者将用于与其他已识别事件清楚地关联的术语进行调整来重新定义事件描述。

在此步骤中，您将专注于主线“快乐”的端到端路径，以避免在异常和错误处理的细节中迷失。以后可以添加例外。

第3步：找到边界

此过程的下一步是通过查看事件来查找系统的边界。可以出现两种类型的边界。第一种边界是时间边界。通常，特定的关键事件表明从系统的一个方面到另一个方面的变化。这种变化可以在从一个人到另一个人的交接中发生，但也可以在地理，法律或其他类型边界的变化时发生。如果您注意到事件便签上的术语在这些边界处发生了变化，那么您将看到域驱动设计术语中的“有界上下文”。通过将蓝色画家的磁带垂直放在事件后面突出显示关键事件。

第二种类型的边界是主题边界。您可以通过查找以下条件来检测主题边界：

• 您有多个同时发生的一系列事件，这些事件只会在以后汇集
• 在一系列事件的事件描述中使用相同的术语。
• 当您重播时，您可以从不同角色的角度“阅读”一系列事件。

通过水平应用蓝色画家的胶带，将墙分成不同的泳道，指示这些不同的同时事件流集。

此图是一组有序域事件的示例，其中指示了关键事件和主题泳道。此示例来自将事件风暴应用于集装箱运输领域，并在“集装箱运输分析”示例中进行了更详细的讨论。

 

第4步：找到命令

在此步骤中，您将从域分析转移到系统设计的第一阶段。到目前为止，您试图了解域中的事件如何相互关联，这就是域专家参与至关重要的原因。要构建一个实现您感兴趣的业务流程的系统，您必须继续讨论这些事件是如何发生的。

命令是用于创建事件的最常用机制。查找命令的关键是询问“为什么会发生此事件？”在此步骤中，流程的重点将转移到导致事件的操作序列。您的目标是找到事件记录效果的原因。预期事件触发器类型的示例如下：

• 人类操作员做出决定并发出命令。
• 外部系统或传感器提供刺激。
• 事件由策略产生，通常是前体事件的自动处理。
• 完成一段确定的经过时间。

在此示例中，触发命令在蓝色粘滞便笺上标识。此命令可以在以后的实现中成为微服务API。发出命令的人物角色在黄色便条上标识。在步骤5的图表中，制造商演员请求在集装箱中交付货物的报价。当报价到达时，制造商使用发货订单命令来创建装运订单放置事件。

您可以链接事件和命令，如“概念”部分中的分析图所示。

第5步：描述数据

如果不了解命令运行以生成事件所需的数据，则无法真正定义命令。您可以在此步骤中识别多种类型的数据。首先，用户（角色）需要来自用户界面的数据才能在运行命令之前做出决策。该数据构成CQRS实现中的读取模型的一部分。对于每个命令和事件对，您添加了做出此类决策所需的预期属性和数据元素的数据描述。下图显示了从装运订单操作的位置创建的装运订单放置事件的简单示例。

在此步骤中，您还可以更全面地描述可以触发从上一个事件或一组事件生成事件的策略。

第一级数据定义可帮助您评估微服务范围和责任，因为您开始看​​到从几个相关事件中使用的数据中出现的共性。这些概念在下一步中变得更加明显。

第6步：确定聚合

在域驱动设计中，实体和值对象可以独立存在，但通常关系是实体或值对象没有其上下文时没有值。聚合通过构成一个或多个实体的根和通过生命周期链接在一起的值对象来提供该上下文。在事件风暴中，聚合通过对相关事件和命令进行分组而在整个过程中出现。此分组不仅包含相关数据（实体和值对象），还包含由该聚合的生命周期连接的相关操作（命令）。最终，聚合建议微服务边界。

在此容器装运示例中，您可以对命令和事件对及其关联数据进行分组，这些数据与运输订单的生命周期相关。

第7步：定义业务环境

在此步骤中，您可以使用在明确边界内有效的明确含义来定义术语和概念。术语定义可以在为应用程序开发的业务单元之外进行更改。

第8步：展望未来

在事件驱动架构解决方案的风暴中，包括额外的步骤来识别有用的预测分析洞察。

Insight storming通过展望并考虑如果您事先知道事件将要发生可能会发生什么，扩展了基本方法。这些知识如何改变你的行为，你会在事件发生之前做些什么？

将洞察力视为将分析扩展到派生事件。衍生事件不是过去事件的事实记录，而是前瞻性或预测性事件。也就是说，“这个事件可能会在接下来的n个小时内发生”。

通过使用这种前瞻性洞察力和来自早期事件的已知业务数据，人员和事件触发策略可以更好地决定如何在新事件发生时做出反应。在洞察力冲击中，您询问研讨会参与者，“哪些数据对每个事件触发有帮助，以帮助人类用户或自动事件触发策略来决定如何以及何时采取行动？”

推动使用事件驱动架构的一个重要动机是它简化了高响应系统的设计和实现。这些系统以个性化和上下文感知的方式立即和智能地做出反应，并在新事件发生时对其进行最佳响应。这种反应性表明，预测分析和生成预测性见解的模型可以发挥重要作用。

预测性分析洞察力是关于未来事件可能发生的有效概率陈述以及这些事件的可能属性。这些概率陈述是通过使用由数据科学家创建的模型或使用AI或机器学习生成的。关联或连接独立收集的信息源也可以生成重要的预测见解或输入预测分析模型。

事件风暴研讨会的企业主和利益相关者可以在以下几个方面提供良好的直觉：

• 哪些概率见解可能会导致改进或最佳决策和行动？
  • 该操作可能采取对事件发生时立即响应的形式。
  • 该行动可能是主动行为，以避免不良事件。
• 什么综合信息来源可能有助于创建一个模型来预测这种洞察力？

通过基本事件风暴，您可以回顾每个事件，因为事件发生了。当您确定参与者或策略决定何时以及如何发出命令所需的数据时，您可以将注意事项限制为先前已知和捕获的业务事件的属性。在洞察力冲击中，您可以扩展方法以期待并考虑特定事件可能发生的概率以及其预期的属性值可能是什么。如果发生此事件，这些知识将如何改变最佳行动？您是否可以在预期的不良事件发生之前主动采取行动以防止其发生或减轻后果？

在洞察步骤中，研讨会参与者通过添加派生事件以及生成它们的模型所需的数据源来识别价值。添加使用这些问题的洞察力攻击步骤可以改善最终设计中的决策制定和主动行为。

通过识别派生事件，您可以将分析模型和机器学习集成到设计的解决方案中。可以处理，过滤，加入，汇总，建模和评分事件和派生事件源，以创建有价值的预测性见解。

在洞察步骤中使用这些新表示法：

• 派生事件的一种粘滞便笺。在这个例子中，使用淡蓝色粘滞便笺。
• 平行四边形图显示何时组合事件和派生事件以实现更深入的洞察模型和预测。

在开发生命周期中尽早识别预测性见解。识别它们的最佳方法是将此步骤添加到事件风暴研讨会中。

这两个图表显示了集装箱运输分析用例的洞察力测试步骤的结果。第一张图捕获了每个冷藏集装箱的见解和相关联系。它确定何时可以对恒温器设置进行自动更改，何时必须安排单元维护，以及何时必须考虑容器内容损坏。

第二张图捕获了可能触发建议以调整船舶航向或速度以响应某些条件的见解：

• 预计未来路线的恶劣天气预报
• 在下一个停靠港预测拥堵和预期的对接和卸载延迟

活动风暴和用户故事

在敏捷方法中，创建用户故事或史诗是项目管理中最重要的元素之一。 与事件相关的命令和策略可以描述为用户故事，因为命令和决策由演员完成。 演员也可以是一个系统。 对于数据，您必须将创建，检索，更新和删除操作建模为用户故事，主要由系统角色支持。

事件是用户故事的结果或结果。 可以添加事件作为用户故事的验收标准的一部分，以验证事件是否发生。

来自集装箱运输用例的事件风暴工件

K Container Shipment用例演示了验证事件驱动架构的实现解决方案。 此集装箱运输分析示例显示了事件风暴和主要的企业设计思维工件，包括用于监控冷藏集装箱的工件。

What's next

• Check out the original paper about EventStorming by Alberto Brandolini.

• Read A step by step guide to Event Storming, which describes Boldare's experience with conducting event storming workshops.

• Get an introduction to Domain-Driven Design.

• See Eric Evan's book on Domain Driven Design - Tackling complexity in the heart of software.

• Review this collection of Patterns related to Domain Driven Design by Martin Fowler.

 

原文 ： https://www.ibm.com/cloud/garage/architectures/eventDrivenArchitecture/event-storming-methodology

讨论:加入知识星球【首席架构师圈】