在考虑如何对业务模型进行抽象从而建立领域模型之前，必须解决业务与产品、开发之间“沟通”的问题。如何让业务人员和开发人员顺畅沟通，在业务流程设计中不遗漏成败攸关的业务场景?如何才能让业务沟通的过程顺畅过渡到架构设计、编码乃至测试?阿里巴巴技术专家李建结合团队的实际案例，分享了他们在使用 Event Storming(事件风暴) 进行领域建模时的经验、收获和思考。
一 软件研发的困境
“失效”的语言交流
日常研发过程中不同角色经常需要进行各种交流：沟通业务需求、讨论产品原型、讨论设计方案等。每个环节不同角色反复沟通，这是研发过程非常重要的环节。但问题是：我们花费大量时间沟通，真的“说” 清楚了吗?
让我们看两个例子：
上面的两段对话发生在一次项目 Review 的过程中。通过第一个对话，我们能看出不同的角色在沟通的时候遇到了障碍;通过第二个对话说明即便是相同的角色，沟通在某种程度也遇到了障碍。
软件研发的困境
无论传统的瀑布流程还是敏捷模式，软件研发总体上能划分成几个阶段：提出需求，产品设计，研发，测试，最后上线。不同阶段会产出不同交付物，有些比较简单，也有些比较详尽：MRD，PRD，技术方案，验收方案等。在整个过程中，我们还会组织不同会议，或者是线下讨论。
大家想一想，在哪一个阶段暴露了最多的问题?
不管我们多么期望在早期发现问题，然而现实是越到研发晚期越会暴露更多问题。当产品进入测试阶段，当上线后真实数据开始跑起来，当业务同学开始使用产品，这时候问题会像泉水一样主动涌现出来，用户会反馈各种问题：“这个不是我想要的功能”，“XX 和我的预期不一样”等等。通常在软件研发的后期发现很多这种类似的问题。软件研发发展到今天，这个问题依然没有被很好的解决。
阻碍产品正确交付的原因
我们通过下面一个例子来分析什么原因阻碍了产品的正确交付。
当产品同学提出需求的时候，研发同学做了好的回应，但实际上双方想的内容并不一致，这种情况我们称之为表面一致;当产品上线后，产品同学提出需求疑问时，研发同学的回答充满了各种技术行话：定时系统，原子性等。显然大部分产品同学不能理解这些技术行话，对话进入停滞状态，我们称这种现象为沟通障碍。在软件研发中该问题反复的出现：沟通不畅阻碍了产品价值的正确交付。在不同角色进行交流时，三个原因阻碍了沟通的顺畅进行：
- 得到的信息不同：产品同学和业务同学关注的是业务需求，市场情况，近中远期规划，以及运营数据等;开发同学关注的是一个个具体的需求列表，功能点，是实现层次的细节信息。
- 思维方式不同：产品同学关注业务/需求的合理性，产品逻辑，用户体验;而开发同学关注方案的可行性，实施成本，系统稳定性等。
- 沟通语言不同：产品同学用描述性的语言，语言的模糊会导致不同角色理解的不同;而开发同学习惯使用技术语言，SDK、数据库、一致性等。不同角色交流的时候，会因为语言不相容，沟通不到一起去。
由于以上的原因，沟通容易陷入“鸡同鸭讲”的窘境：讨论很热烈，甚至能取得表面的一致，实际并没有“说”清楚。
洞察软件研发困境
Event Storming 方法的发明者 Alberto Brandolini 认为：产品体现了程序员对业务的理解(或误解)。很多时候沟通失败导致的误解进入产品实现。于是真正的业务需求在产品中没有得到体现。沟通失败是软件研发的一个痛点，有待解决。
二 Event Storming
Event Storming 介绍
Event Storming(ES)：由不同角色共同参与，用彩色贴纸进行交流的工作坊。
如上图，一群同学围绕一个业务场景，用贴纸进行交流，这就是 ES 工作坊。通过贴纸进行交流，让大家用同一种沟通语言，同一个思维方式，让大家的思维在一个频道上，这是 ES 的形式，也是 ES 的目的。
Event Storming 语法
ES 定义了一套彩色贴纸的“语法”：不同颜色的贴纸都有定义。浅黄色代表 Actor (角色)、蓝色表示 Command (命令)、粉色代表 Policy (业务规则)、浅粉色代表System(系统)、橙色代表 Event (事件)，浅绿色表示 Read Model (读模型)、红色代表 HotSpot (热点/问题)。
用 ES 的语法表达用户的下单流程：买家 (浅黄色贴纸) 提交订单(蓝色贴纸)，如果订单里商品是在线状态，购买量小于商品库存量 (粉色贴纸 Policy) ，那么订单创建成功(橙色事件贴纸)，已创建的订单 (绿色贴纸) 展示给用户。订单创建后需要通知买家(业务规则，粉色贴纸)，系统执行发送站内信(蓝色贴纸)。
如何在业务中使用 ES
下面我们通过一个业务场景(优惠券的投放和使用)介绍如何使用 ES。
业务背景介绍
电商网站提供各种优惠券：满减券，折扣券，有无门槛券。
下图描述电商运营小二在活动中投放优惠券的整体流程：小二先创建优惠券，然后再创建一个活动，把优惠券和活动关联起来。活动通过公司财务的审批后才可发布上线。消费者在活动页面领取优惠券，在下单流程使用优惠券抵消金额。最后活动结束时要对整体活动的数据进行统计分析。
准备 Event Storming
在开始 ES 前，先做好准备：
- 准备物料：彩色贴纸、笔纸、一个足够大的房间等。房间里不要有椅子，因为在 ES 过程中，我们希望大家都全神贯注的投入，而不是坐在椅子上开始放松。
- 邀请正确的人：有问题的人和有答案的人。程序员、交互设计师、测试等都是有问题的人，需要通过 ES 理解业务和产品;有答案的人通常是用户、业务或产品，他们通常能回答业务的背景，诉求和目标。
Event Storming 的过程
ES 可以分为开场介绍、ES 沟通业务和讲故事三个阶段。
开场介绍
在 ES 中有一个特殊的角色叫做 Facilitator(推动者)，一般是 ES 的组织者。在 ES 开始前，Facilitator 向大家介绍 ES 是什么，有什么好处，以及彩色贴纸的用法。然后介绍讨论的范围和目标。
比如，今天讨论优惠券场景，目标是理清营销活动过程中优惠券的业务流程。最后 Facilitator 强调 ES 的规则：所有的讨论都写在贴纸上;不允许使用电脑，手机;也不允许坐下。在 ES 的后续过程中，Facilitator 还需要承担另外两个重要职责：保持参与者的专注，通过提问驱动交流。
ES 的方式沟通业务
第一步先梳理事件(橙色贴纸): 事件是已发生且重要的事情。事件必须是既成事实，且业务关注的事情。通常 Facilitator 会先准备第一个事件(可以是系统中任一事件)， 然后把它贴到墙上。
假设第一个事件是：优惠券已领取。接下来 Facilitator 通过提问引导大家找到更多的事件：
- 事件发生前有哪些事件(“优惠券已领取”前须先有“活动已发布”事件)?
- 事件发生后下一个事件是什么(“优惠券已领取”后有“优惠券已使用”，“优惠券已过期”等事件)?
提问会引导参与 ES 的同学将新发现的事件不断补充到墙上。事件要保持整体的时间顺序：先发生的事情贴在左边，后发生的事情在右边。通常大家容易关注系统的正常流程，也就是 Happy path。这时候 Facilitator 需要引导大家关注业务的非正常流程 Unhappy path。边界条件，异常情况通常是业务复杂性的重要原因，也是非常容易被忽视的部分。
- 事件一定会发生吗(优惠券一定领取成功吗?不是，贴上“优惠券领取失败”事件)?
追问 unhappy path 梳理出业务的完整视图，当大家发现新事件的速度接近停滞的时候，就应进入梳理业务规则的阶段了。
Policy，业务逻辑或规则，这是业务中最重要的部分。Facilitator 会提出以下问题：
- 事件是否一定成功?如果不是，那么成功的前提条件是什么?
- 该事件是否会导致其他事件的发生(Reaction)?
例如“活动已提交”事件：
- 活动提交成功的前提条件：活动已关联有效优惠券，且已选择了生效方式，并且选择了适用人群。
- 活动提交后，会导致审核任务已创建事件，这里的业务规则是：活动提交或需创建审核任务。
接下来找出三个角色：Actor (和系统交互的人)，Command (用户动作) 和 Read Model (辅助用户决策的工具)。Facilitator 提出以下问题：
- 是什么触发了事件?即事件发生的原因 (ES 的语法：when Event， then Command)。
- 谁执行了动作。是人，系统，还是时间(例如定时触发的事件)?
- 做出动作前，用户需要获取哪些信息?
以上的问题会引导大家找到 Actor, command 和 Read Model。 在营销活动已提交事件中：小二(Actor)执行了提交活动(Command), 从而产生了“活动已提交”事件。
最后介绍 Hotspot：业务痛点、瓶颈、模糊点。Hotspot 是 ES 过程中随时都应该发现并记录下来的。Facilitator 可以引导大家发现业务中未描叙到的问题，例如：用户使用优惠券进行支付的场景中，如果用户支付失败，已使用的优惠券该如何处理呢?优惠券应该返还给用户，还是不做处理?通过提出这样的问题，引导大家对业务流程进行更深入的讨论。通常在 ES 的过程中，识别并记录 Hotspot，不要在 ES 中尝试解决所有的 hotspot。
以上介绍了 ES 的主要元素：Event，Policy，Actor，Command，Read Model，Hotspot。用 ES 描述了优惠券发放的业务流程，最后一步是“讲故事” (storytelling) 的阶段。
讲故事
Facilitator 邀请不同的人担任志愿者，每个志愿者讲一段故事：按时间顺序和 ES 描叙的逻辑， 向其他人介绍业务流程。过程中，听众注意到不一致的地方随时提出问题，大家讨论问题，通过增加/删除/移动贴纸来修复问题，并继续讲故事的流程。
最开始大家会按时间正序讲故事，最后大家还可以倒序讲故事。梳理业务的异常场景，倒序讲故事的方法更有效。例如为什么会发生“优惠券领取失败”事件，事件的原因是 balabala…
经过讲故事阶段的完善，大家获得了业务的完整理解，这时候可以结束讨论，保存相关材料，遗留下来的 Hotspot 交由相关同学跟进。
Event Storming 常见问题
ES 比其他方式更能帮助大家顺畅的沟通，但是对于首次参与或组织 ES 的同学也有一些疑问。 以下列出一些常见问题：
Q：ES 通常邀请多少人参加?我需要邀请所有角色吗?
A：不一定。ES 鼓励不同角色共同参与，但是参与人的态度更重要，积极主动参与是 ES 成功的关键。通常一个 Pizza (8 - 10人) 的规模，是适合 ES 人数。
Q：我的业务场景和复杂，在 ES 中要梳理完整个业务流程吗?
A: 不需要。ES 需要大家高度参与，因此需要控制好时间。每次 ES 的范围选择复杂业务场景的一部分，保证 ES 的效果。
Q：我应该在什么阶段做 ES?
A：项目的任何阶段都可以做 ES。ES 既可用于梳理业务现状，也可以用于设计业务的未来方案。
Event Storming 小结
下面的四个图直观的解释了 ES 的作用：
- 图 1，说明不同角色通过语言交流，虽然达成表面一致，实际上大家理解不一致。
- 图 2，ES 要求大家通过贴纸的形式可视化出来脑海中的想法，从而使分歧自动显现。
- 图 3，ES 通过不断的提问触发讨论，从而能够拉通认知，消除分歧点和模糊点。
- 图 4，ES 拉通了大家对业务的理解，从而达成了真正的共识。
总的来说，ES 让不同的角色用同一种语言(彩色贴纸)从全局对业务达成共识。
从 ES 到代码
简单介绍下 ES 如何顺畅过渡到 DDD(Domain-Driven Design 领域驱动设计)。
提取业务概念
DDD 中最重要的是统一语言：交流使用统一语言;模型表达统一语言;代码表达统一语言。语言是由概念组成的，ES 的过程已经将概念写在贴纸上，并且在交流中反复使用。例如：优惠券，营销活动，已领取优惠券，领取方式，人群等。
一部分概念有生命周期，并且有唯一的标识符。例如：营销活动，优惠券，已领取优惠券。这些就是 DDD 中的实体;还有一部分概念标识一个完整的业务含义，但是没有生命周期，并且属性相同的两个对象可以替换，这些对象就是 DDD 中的值对象，例如：领取方式，生效方式，人群。
提炼模型
概念和概念之间是有关系的。比如说，优惠券和营销活动有关联关系，已领取优惠券是在某个营销活动下领取的，营销活动也包含很多信息，它的生效方式是什么，领取方式是什么，人群是谁。概念与概念之间的关系也就是领域模型。
从模型到实现
将 ES 贴纸重新组合：围绕一个核心概念，将与该概念有关的 Event，Command，Policy 组合在一起。例如下图左边围绕营销活动为中心重新组织了贴纸(Command，Policy，Event)，这些贴纸和右边的代码映射起来，这也就是 DDD 中说的代码表达统一语言。到此，简单介绍了如何从 ES 到概念，从概念到模型，以及模型和代码实现是怎么关联起来的。
架构，代码和约束
下图简单描述应用架构，代码结构，以及如何通过 ArchUnit 实现架构约束。
四 总结
ES 的价值在于：不同角色在具体业务场景下用一种共同语言(彩色贴纸)进行交流，通过不断提问触发探索、讨论，最终达成真正共识。
