事件风暴EventStorming 是一种非常流行的技术，它使我们能够比传统技术更有效地探索、分析和建模业务领域。结果是我们创建了设计更好的软件系统和问题解决者团队，而不是订单接受者。
如果使用得当，EventStorming 让我们能够发现关于我们的领域和我们的业务的足够信息，我们可以用它来设计我们的微服务、限界上下文，甚至我们的团队。
然而，在公共培训课程和为客户私下举办过许多 EventStorming 课程后，我们注意到，EventStorming 的应用可能会导致人们质疑其价值，并让他们觉得自己在浪费时间。
另一方面，当 EventStorming 得到有效应用时，我们已经看到很多成功的会议，其中许多团队都使用 EventStorming 作为其微服务设计的基础。
在本文中，我们将分享一些易于学习的技术，它们将帮助您充分利用 EventStorming，从而设计出更多与领域一致的软件系统。
1. 避免过早抽象
一个团队在开始使用 EventStorming 时可能采取的错误转变之一是在过高的级别上对他们的域流程进行建模。他们认为“这很简单，我们在这里学到了什么？我们不要再在 EventStorming 上浪费时间了。”
在许多 EventStorming 会议中，杀手级领域洞察力是通过在更深层次上对领域建模来解锁的。在这里，您可以打破幻想、测试假设并了解您的领域的实际运作方式。这使您能够超越简单的软件模型，实现真正的领域驱动设计。
让我们以在线工作委员会为例：
招聘海报签约：
他们创建了一个配置文件。他们发布招聘广告。求职者申请这份工作。职位发布者安排面试。求职者得到了这份工作。
这就是域的工作原理。但它是如此肤浅，如此高层次，它没有教给我们任何东西。我们可以模拟更多的流程，比如工作申请被拒绝，这让我们觉得我们已经对我们的领域进行了深入的建模，但它仍然太高了，任何人只要看一下网站就可以解决
2. 从具体场景入手
为避免过早抽象，请从对单个细粒度流建模开始。例如，特定类型的用户在特定时间以特定价格购买特定产品。
对单个流建模后，在流中寻找子分支，然后分解到相邻流。
在职位发布领域，我们可以从为注册发布职位的外部招聘人员建模开始。购买大型计划的外部招聘人员，然后是购买小型计划的外部招聘人员。
我们需要根据我们正在招聘的业务来组织招聘广告。而且，订阅政策有一个意见：如果你正在招聘多家公司，你必须承诺采用不同的订阅模式——这会影响你的计费方式和你收到的报告类型。与其他类型的工作海报非常不同。
当您在更精细的级别建模时，您将开始看到分支、扇出、扇入和各种流程模式。例如，外部招聘人员受制于不同的订阅计划，需要特殊的工具来组织他们的工作，需要不同类型的报告，
这些是关于您领域中自然属于一起变化的部分，以及看起来相同但关系松散得多的部分的超级重要线索。这种类型的信息是构建领域驱动软件系统的关键。
3.捕捉隐藏的意图
我们看到许多初学者犯了将Form Submitte事件添加到他们的 EventStorm的错误。这不是领域事件，它是领域事件的技术实现。重要的是为什么要提交表单——用户的意图是什么？
除了使用Form Submitted，您还可以添加一个更专注于域的名称，例如Job Posted。
这是领域术语，但仍然不够。在对域中的数据提交进行建模时，可以使用以下技术来获得更深入的域洞察力：
- 列出每个单独的数据（即表单上的每个字段）
- 枚举每条数据的可能值
- 理解不同价值观的意义
- 将显着差异建模为单独的流
举个例子可以更好地说明这一点：发布职位时，提交的表单包含字段：就业类型。它可以是Permanent或Contract。该选择具有很高的领域意义，会导致业务流程发生变化，从而影响业务成果。
因此，在这种情况下，也许两个事件更好：Permanent Job Posted和Contract Job Posted。然后对这些过程中的每一个进行建模——寻找过程中的差异并寻找相似之处。您将深入了解设计系统的最佳方式，尤其是设计微服务边界的方式。
4. 对 CRUD 命名持怀疑态度
带有Created、Updated、Changed或Deleted等通用后缀的事件表明您正在使用技术术语而不是真正的域术语来描述您的域。
更新可能是最大的警告信号。更新是一个非常通用的术语，基本上意味着已更改。当我们使用 EventStorming 时，我们试图捕捉我们领域的丰富性，所以我们应该问“为什么要更新某些东西？”。
对 CRUD 命名持怀疑态度不仅可以帮助您开发更丰富的领域词汇表，从而改善技术从业者和领域专家之间的协作，而且还可以帮助您发现领域内的其他流程。了解每个不同的变更原因，您将发现许多领域见解。
您可能没有在您的 EventStorm 上设置价格更改事件，而是设置了价格折扣、季末销售价格应用、圣诞节促销价格激活或您的域特定的其他内容。
5.寻找状态机和关键事件
状态机几乎在每个领域无处不在。我们正在建模的概念经历不同的生命周期阶段，它们的状态。
如果您特别强调寻找状态机，您将更容易发现域中的边界，这些边界将成为您的微服务的边界。
有一种特殊的事件用于识别状态机状态之间的转换，称为关键事件。关键事件是领域边界的有力指标。
在物联网设备领域，我们可能有以下关键事件：设备制造、设备配置、设备安装和设备激活。虽然在整个过程中发生了数百个事件，但这些都是标志着重大变化的关键业务事件，例如将设备从仓库移出并安装在公共场所。
6. 到处问“如果？”
很容易陷入只对域中的常见或快乐路径场景建模的陷阱。但是，通过探索所有边缘案例也可以学到很多东西。
要梳理出您领域中的边缘案例，请查看墙上的每个事件并问“什么？”。“停电了怎么办？”，“客户刷卡被拒怎么办？”，“仓库着火了怎么办？”。
对该领域有强烈的兴趣和好奇心会导致您提出探索性和挑战性的问题。这将引导您获得有关该领域的许多见解。
7.如果组正在挣扎，切换到单线程模式
混沌探索是 EventStorming 的标志之一，整个团队单独集思广益。每个人都可以自由地将自己的所有想法、假设和顾虑放在墙上。
混沌探索对于 EventStorming 提供的许多发现至关重要。然而，有时能量低下，团队混乱，或者由于许多可能的原因之一而没有取得进展。你能为这个做什么？
虽然只有一个人在其他人都在看的情况下将便利贴贴在墙上被认为是一种反模式，但这种称为单线程 EventStorming 的方法在帮助团队达成一致和构建方面可以出人意料地有效势头。
此模式有一些变体，但您可以尝试开始：
- 选一个人把便利贴贴在墙上
- 其他人都坐在/聚集在他们周围
- 选择一个特定的用例模型
- 向前推进，一次添加一个事件，确保小组在继续之前达成共识。如果小组陷入僵局，请记下来并稍后返回
- 如果有任何其他疑问或疑虑，请记下并稍后返回 - 保持进展
在短暂的单线程会议之后，小组将有许多想法和他们想要更详细地建模的其他场景。是切换回混乱模式的好时机。
掌握事件风暴和微服务设计
了解您的业务领域是设计最佳软件系统的关键。因此，提高您对业务领域建模的能力将增强您作为系统设计者的能力。
EventStorming 是可用于为业务领域建模的最佳工具之一。您对 EventStorming 的掌握越多，您在构建满足业务需求的软件系统方面就越成功。
掌握 EventStorming 不是五分钟就能学会的。但是你越早开始学习，练习得越多，你就会越快到达那里。我们希望我们在本文中分享的技巧将有助于加速您的精通之路。