大局事件风暴（BPES）主要分为以下几个阶段：
1. 做好准备：确定参与者，包括业务专家、开发人员、架构师等，准备必要的工具，如便签、马克笔和大白板或者其他可以粘贴便签的平面。
2. 事件发现：所有人员共同讨论并记录业务流程中的重要事件，这些事件将被写在颜色鲜明的便签上。
3. 排序：将记录的事件按照发生的先后顺序进行排序，形成一个时间线。这有助于对整个业务流程的理解。
4. 热点发现：在事件的讨论过程中，可能会出现一些争论和问题，这些就是所谓的“热点”。找出并记录这些热点，为之后的深入探讨提供线索。
5. 命令和聚合识别：识别出导致事件发生的命令（动作）以及这些命令和事件所属的聚合（业务实体或组件）。
6. 结论和下一步计划：总结会议的结果，确定要解决的问题，制定后续行动计划。
这个过程可以根据实际情况进行调整，不同的团队和项目可能会有不同的具体实现方式。
大局事件风暴之后的下一阶段是流程级事件风暴 (PLES)。在 PLES 中，我们专注于解决方案，并按照我们希望的方式对事物进行建模。此外，还会出现一些新概念，例如命令、读取模型和业务规则。
准备好，稳住，出发！
在我们的第一次会议之前，我将域描述发送给了大家，并将一些原始线框图上传到了我们的 Miro 板上。我们有它们供参考，因此我可以快速解释示例中的流程。
然后我们开始进行混沌探索。我们每个人都在板上放置事件。首先出现了问题、想法和讨论。我们决定将“好的想法”标记为绿色便签。这是一个好的做法，因为它通常能激发创造力。过了一会儿，我们的板子看起来如下：
请仔细看一下，并试着参考第一篇文章中的领域描述。你可以发现这里的一些事件被组织成了某种批次/组。这是在Miro中使用“批量模式”功能的结果。在研讨会的早期阶段，这是一个有用的功能，因为它允许参与者一次添加几个事件。你可以将它们作为行添加到一个单独的模态表单中，提交后，它们被添加为“便签”到板上。
在这个阶段，所有的事件都被随机添加了，所以我们开始了下一阶段 - 强制时间线。我的任务是叙述整个故事。与此同时，我可以添加关于某些部分的一些额外信息，所以我们进行了一些额外的讨论。然后，Mariusz提出了他称之为“神奇四人组”或“0，50，100，150”的启发式规则。当我们观察到一个“二元”事件时，我们通常可以使用它 - 事情要么发生（100%），要么没有发生（0%）。有时我们有两个额外的情况：某件事部分发生了（50%）或者过多的发生了（150%）。在我们的案例中，这样的事件是“广告需求被接受”。我在这里有一个是/否的思维模式：招聘者接受或不接受需求。Mariusz建议我们可以试着使用“神奇四人组”启发式规则，因为在现实世界中，这种情况有谈判的余地。例如：“我们不允许远程工作，但你可以带你的宠物来上班。”我们记下了这个想法，以便在研讨会的后面部分考虑它。
好的，现在让我们回到剩下的活动。我们现在已经按正确的顺序排列了它们。我们还没有删除任何重复项或不必要的事件。尽管如此，我们还是标记了整个过程中一些较小的、相当独立的部分，告诉我们可能的子域。它将帮助我们专注于流程级别中较小的部分。
最后看板如下
在下一步，我们画了一条线来分隔我们的工作成果。我们开始在这条线下只放置领域事件 - 这些事件会在我们的系统状态中引起一些真正的变化。同时，我们删除了一些重复的事件。我们还同意跳过在第一轮迭代中不会实施的功能的事件。结果，我们能够可视化我们的第一个业务过程和业务模型。
为了移除所有“不必要”的事件，我们使用了另一个有用的启发式方法，它集中在事件类型上。区分了四种类型的事件：
环境事件 - 存在于系统外部 - 在真实世界中，例如，一个人走进商店。它们通常对研讨会不是关键，但是它们有助于获取上下文。
UI事件 - 我们在点击/使用UI，但是我们不“提交”我们的选择。我们没有改变系统的状态。例如：我们可以在UI上多次选择定价计划，但是直到我们确认我们的决定，我们的系统中实际上什么都没有发生。
基础设施事件 - 指的是技术性的事情，并且对系统没有任何影响：“发送到Kafka的事件”，“度量增加”。
领域事件 - 事件风暴的核心。在我们的研讨会中，我们应该只关注这些事件。
使用上述假设和启发式规则，我们改变了大局如下：
现在让我们从左到右一点一点地看看发生了什么变化。
首先，我们删除了所有与潜在客户开发相关的事件：
之后我们又做了如下改动
这里你看到我提到的第二种启发式方法在实际中的应用 —— 关于不同类型事件的那个。我们移除了所有的UI事件。请注意，“添加证书”或者“标记远程工作为必需”并没有改变系统的状态。那些只是在UI上的操作。换句话说，我们正在准备广告的草案。我们可以将所有这些事件描述为一个：“草案被修改”。实际上，如果我们决定在我们的系统中没有草案的概念，我们这里可能一点儿事件都没有。然而，我们想要有草案，因为我们希望用户即使暂时离开也能继续准备过程。否则，我们可以删除所有与草案相关的事件，通过UI处理所有事情，并且只在表单提交和广告进入系统时有一个事件。
当广告准备好后，我们进入支付和发布过程：
同事指出，如果广告在一段时间内有效，也许我们不应该继续制定一些定价计划，而应该出售时间。如果用户希望广告在搜索结果中停留更长时间，那么他们需要额外支付几美元。我们喜欢它，第一个商业模式就这样诞生了。多亏了这一点，我们可以跳过定价计划的所有部分。顺便说一句，我们还在这里放置了热点（粉色便签），只是为了标记我们有一些担忧的地方。
最初，我也有个想法，那就是在发布后，广告就只读了。我只是想防止招聘者接受开发人员的要求后，但随后要求被更改，从而产生一些不一致性的情况。实际上，只读模式可能真的很让人烦恼。想象一下，你打错了字，想在一两天后修正。解决这个问题的第一个想法是在发布后给用户X分钟的时间来编辑广告。这就是为什么你在第一版中可以看到一个“广告编辑时间过期”的事件。但后来我们意识到，招聘者接受的是开发人员在给定时间点的要求。这使我们想到了像“快照”这样的东西 - 针对特定要求的提议。
现在到了最后一个流程——候选人验证：
我决定将这个过程包含在产品的第一个版本中，因为它展示了如何与外部系统集成。而且，这是一个长期运行的过程。由于广告是匿名的，我想给开发者一些展示他们技能的可选可能性。换句话说，他们可以在外部系统中解决一些测试后获得徽章。您可以注意到指定准备就绪和测试开始的事件有所减少。那是因为这些事件不在我们的领域之内，它们属于外部系统。我们只想开始我们的验证并在问题解决后得到测试结果。
当谈到我们的大局事件风暴时，就是这样。在下一篇文章中，我们将进行流程级事件风暴并对每个流程进行详细建模。
