事件风暴
本文译自事件风暴提出编写文件: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?
运行一个实验并没有那么困难。所有你需要的是:- 一个合适的房间,安静且足够大以容纳建模表面(如果天气允许,也可以选择户外建模,但风可能是主要障碍);
- 一个可写的表面,很可能是宜家纸卷(代号 Måla,您可以在儿童区找到它)。
- 大量不同口味的便签(基本套装是淡黄色长方形便签,外加橙色、蓝色和紫色方形便签);
- 工作标记,理想情况下每个参与者一个加上备份;
- 一些美纹纸胶带,以防万一;
- 合适的人。
- 一个促进者。