Dan North 在最近伦敦举行的 DDD eXchange 大会上的演讲中声称，在领域驱动设计（Domain-Driven Design， DDD）的概念中，事件风暴是非常有用和有价值的。他解释了事件风暴的基本机制，并分享了他近几年为各种不同系统建模的经验。
事件风暴就是把所有的关键参与者都召集到一个很宽敞的屋子里来开会，并且使用便利贴来描述系统中发生的事情。一张桔黄色的便利贴代表一个领域事件，在上面用一句过去时的话描述曾经发生过什么事情。为了让自己关注最终目标，North 经常从结束时的最后一个事件开始，然后把第一个事件加上来，就有了一个从开始到结束的完整时间表。
其它常见的便利贴有：
- 用蓝色的便利贴来为被命令触发的事件建模。命令的发起者可能是人，是注入到系统中的外部事件，或是定时器等
- 用粉色的便利贴来为疑问或难题建模
- 用绿色便利贴为人们看见了什么或者想看见什么建模，即视图或者阅读模式
North 也表示并不一定要用这种方法，他建议使用对你建模的问题最有效的办法。
North 说事件风暴最强大之处在于为结果建模。我们对发生过什么事情感兴趣，我们就知道事情将来可能的结果集。用传统方法时我们总是围绕着过程、活动和人的行为建模，这太受限了，因为最终都是从人的行为开始。如果换个角度我们关注这些活动的结果，把它们建模为事件，我们就有了另外的作法。
事件风暴如此有效的原因在于很多有用的工作都是并行完成的。人们总是关注他们自己日常做的那一块，这样就自然而然地把人按工作内容给分了组，每个组在做模型的不同部分。这样就产生了模型里面的聚集或者叫子系统。象经理这样的知道整体流程的人则从全局的角度去看待它，检查确保所有的子系统最后可以整合得起来。
建模的过程中有一个非常重要的步骤是问什么事件是必要的——就是那些要得到结果就必须要发生的事件，与其对应的是那些只做为流程的一部分发生又不会影响结果的事件。这个问题可以把那些不必要的事件剔除掉而显著的简化整个流程。
North 说事件风暴与影响图谱、故事图谱和其他的协作发现活动等都是针对相同问题域的。他会使用事件风暴来让团队达成共识，然后使用影响图谱来获得方向感，最后使用故事图谱来找到开发和提交软件的方法。
Vaughn Vernon 在一个早些的演讲中提到事件风暴对于定义模型应用的上下文、为模型划定边界是一个非常重要的工具。
事件风暴的发明者 Alberto Brandolini 最近在写一本书： Introducing EventStorming 。
明年的 DDD Exchange 大会计划在 2017 年四月下旬召开，现在正开放注册。
查看英文原文： Experiences Using Event Storming
感谢夏雪对本文的审校。
给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们。
暂无签名
分布式云行业实践指南（2023）
业内首个分布式云行业实践方法论、工具箱。
评论