什么是Event Storming
在谈论Event Storming的时候，我们常常会把另外两个概念放在一起谈论，它们是DDD和微服务。所有有必要先把这三个概念区别一下。以下是从一个BA的视角出发来尝试理解它们之间的关系。
Event Storming, DDD 和微服务的关联性体现在它们都是为了解决同一个问题，即软件开发的固有困难。
软件其实是将物理世界的概念、关系、结构、流程映射到计算机世界中，以便利用算力的优势解决现实世界中的问题。那么在映射的过程中，就会存在两个问题：
1. 本质问题：打造由抽象软件实体构成的复杂概念结构；
2. 非本质问题：使用编程语言表达这些抽象实体，在空间和时间限制内将它们映射成机器语言。
其中，非本质问题虽然也会一度造成软件开发的巨大困难，但随着技术的改进，是可以被消除的。例如，高级语言的发明就彻底的解决了程序员需要直接编写汇编语言的困难。
相反，本质问题则是软件开发所固有的，在本质上是不会被彻底解决的。因此，构建复杂的概念结构就成了软件开发的主要困难。
为了解决这个困难，微服务作为一种架构风格尝试控制软件复杂度，通过将单体应用拆分为一个一个的微服务把应用内部的复杂度化解，并转化到服务与服务之间。固有的复杂度虽然不会被消除，但是通过这样的方式使其可以被很好地控制，从而更好地响应业务变化。
而DDD作为一个理论体系指引了通向微服务的光明大道。DDD是在理论层面告诉我们如何将业务架构和技术架构保持一致性，如何进行架构设计。它是一种设计思想，设计原则和设计过程，也为真正实现微服务架构提供了一套方法论。
以上并没有解决具体该如何做的问题，Event Storming则给出了一个答案。它将DDD落地到实践层面，通过预设计的一系列工作坊，将技术人员和领域专家撮合在一起，通过可视化、高互动的方式一步一步将领域模型设计出来。
所以整体来看他们之间的关系大约是这样的：
如果我们稍微类比一下产品设计领域中的一些概念，会发现竟有类似之处（并不准确）：
总结一下，Event storming是基于DDD思想的一套实践工具，利用这套工具可以便捷地实现微服务划分。
下面，通过近期我的一个项目经历来看看Event Storming一次具体实践。（注：本文不涉及Event Storming的具体内容和实践步骤，如果不了解的可以阅读Event Storming发明者Alberto Brandolini的《Introducing EventStorming》）
Event Storming的一次实战
项目背景
国内某PC生产厂商的IT部门，希望对其订单状态跟踪系统进行服务化改造。因为现有遗留系统由于本身架构设计等原因已经难以承接业务部门的新需求了，加之原来的产品开发团队人员流失，导致现在的系统成了一个黑盒，没人能搞清楚里面的逻辑，也没人敢碰里面的代码。
IT拿着BU给的一笔预算，名义上是做产品的二期特性增强，其实诉求是对一期产品做服务化改造。现在这已经成了业界大厂商IT部门的一个不成文的套路。
Inception
在接到这样的需求之后，我和一个Tech Lead入场，开展了为期两周的Inception（注：这里的Inception泛指项目启动过程，所以也包括后面要介绍的Event Storming工作坊）。
这种类型的项目不涉及太多新功能和页面设计，主要是对现有业务流程的梳理和技术架构的重新设计。所以，微服务项目的Inception一般无需UX参与，视业务复杂度的情况，配备1BA+1TL，或者1BA+2TL即可。
Inception前半段走标准流程，与一般项目没有太大差异：项目启动-愿景梳理-干系人分析-用户画像-用户旅程。以这个项目为例，最后的用户旅程的产出如下。
通过以上的几个步骤，基本对于业务全景有了理解，并且以从系统外向系统内的视角，将整个产品端到端的使用场景串联了一遍，对产品的核心功能，核心业务逻辑梳理了一遍。
Event Storming启动
用户旅程的产出是Event Storming的输入。基于用户旅程，我们可以将其拆分为几个主要场景，并分别针对每个场景开展Event Storming工作坊。鉴于篇幅有限，这里主要以用户注册的场景为例。
Event Storming是一个需要客户高参与度的工作坊。因此在正式开始之前，该做的准备工作一定要做好，目的是让客户明白，这个工具解决什么问题？这个工具怎么用？我将如何参与？为什么是这个工具，而不是其他的？可以采取的做法比如：
1. 先花点时间介绍一下DDD，以及Event Storming和DDD的关系。
2. 串讲一下Event Storming的整个过程，明确告诉客户需要他们做的是什么，以及最后期望的产出物。最好能举个例子，以便所有人理解。
3. 把需要用到的工具可视化，比如把用来表示事件、命令、角色、外部系统的不同颜色的sticker贴在白板上，把大致步骤写出来。
4. 分享这套工具在其他客户那里的应用效果，当然主要挑正面的说，而且最好是同一行业的对标企业。
工作坊的引导可以由TL来，也可以由BA。但是个人觉得对于没有技术背景的BA来说挑战比较大，难点在于：
1.流程形式容易走，但是由于没有深入理解背后的思想，所以对工作坊的执行效果和产出物的把控会欠缺。
2.会面临客户IT提出的一些技术问题，难以应对。
3. 整个方法虽然希望拉通业务和技术，但是还是技术导向的。一些工作坊中的操作细节都是从技术思维出发，所以本身对于BA而言，比较难以理解。比如，为什么要先梳理出事件？聚合又到底是什么东西？吐槽一句，聚合这个叫法本身就对于业务非常不友好。
Event Storming进行中
Event Storming的过程按照：事件风暴-命令风暴-识别聚合-划分限界上下文，来进行。整个过程围绕领域事件来驱动，因此基本上工作坊70%的时间都会花在事件风暴这个步骤上。识别事件也是整个过程的一个基石。
引导者将规则介绍完之后，就会让客户头脑风暴，将识别出来的事件写在sticker上，然后贴在白板上。对于没有参加过这个过程的客户来说，不论事先将规则解释的多么完备，放心，最后板上贴的一定是五花八门。这也是正常的情况，因为大家对于这个工具的认知不同，对于业务的理解不同，自己所处的上下文不同，大家的语言不统一。这时候需要引导者在第一个场景的实践过程中预留更多的时间来引导客户思考，澄清业务，统一认知，统一语言。所以第一个场景其实是在练习，以便后续的过程更加顺利。所以建议从一个非核心域的业务场景来开始，一般我们可以选用支持域的，比如用户注册的场景。
在第一个场景的练习过程中，客户会提出各种各样的问题，比如:
1. 打开一个网页算不算一个事件。 应对：注意区分读模型和领域事件。
2. 邮件是系统自动发的，但是我想知道这个状态，因为如果邮件没有发出去，我可以追溯原因。 应对：注意区分系统log和领域事件。
3. 如果事件记录不全对之后的开发会不会有什么影响。应对：事件风暴的最终目的是识别服务，一小部分事件的缺失并不会影响最终产出。
4. 事件的粒度如何把控，是否要抓细节？应对：取决于业务规模和时间限制，还有最终服务的粒度。
5. Event Storming 是项目启动的时候做一次就可以了，还是之后每个迭代开始的时候都要做。应对：需要划分服务的时候就可以做。
Event Storming这套工具本身是一个新生儿，是否好用要经历时间的考验，所以目前肯定会遇到各种各样的问题。在面对客户问题的时候，要注意引导客户不要过多关注在工具本身，而是要关注背后的思想。
在识别出所有聚合之后，就可以基于这些聚合识别问题域，划分限界上下文。每个上下文即可对应一个微服务。
最后，最重要的一点是要为这些问题域分类，它是一个核心域、通用域还是支持域？这虽然对于最终产出的微服务划分没有影响，但之所以重要是因为它关乎产品定位和核心价值。
比如，该项目的产品是一个订单信息追踪系统，最主要的功能就是发送订单状态更新邮件给用户。但其实，我们和客户进行讨论后认为：核心域并不是发邮件，而是订单信息和邮件发送逻辑。这个产品独一无二的竞争力在于，基于订单信息这样的核心数据资产，通过复杂的邮件发送逻辑，能够准确实时地推送客户想要的信息。所以，一旦将这两个问题域识别为核心域就意味着，之后项目资源将向这两个方面倾斜。
在做完event storming之后，建议将识别出来的各个问题域和之前的产品愿景对照一下，看看是否一致。
Event Storming结束后的反思
在客户现场实践过后，还是遗留了很多问题，比如：
1. Event Storming 中的元素：命令和角色，与User Journey中的元素：角色和行为，有些类似。重复梳理他们的过程显得比较冗余。
2. 整个Event Storming的过程以事件为中心，命令风暴和寻找角色本身的意义显得不是特别明确。
3. Event Storming 的思路是从内部向外看系统，先找事件，再找命令和用户。这样的思考方式比较反直觉，且与业务人员的思考方式相反。所以对于大部分新客户，尤其是业务部门，这个工作坊的学习成本较高，参与度可能会受影响。
不仅如此，还有更多的问题可以引发思考：
1. Event Storming 在Inception中所扮演的位置，以及如何与Inception中的其他实践很好的融合？
2. 我们是否可以考虑在其他非服务化项目的Inception中引入Event Storming, 如何说服客户为它买单？
3. 对于Event Storming的产出物，我们关注的是领域事件和划分好的服务, 还是只有服务？如果也关注事件，那么事件后续的应用是什么？
Event Storming 还是一个新工具，相信会在未来的日子里不断演进，至少现在我已经能看到不同版本的呈现了。不管如何演变，只要领域建模对于软件开发是一个复杂问题，那么那些能够解决复杂问题的优良品质一定会被保留下来，比如统一语言，技术和业务的高度协作，不断迭代。
