官方地址
什么是事件风暴
官方定义
事件风暴是一种以协作探索复杂业务领域为目标的，灵活的工作坊（workshop）形式的活动。
它有不同的玩法，适用于多种不同的场景：
发掘现有的健康业务线中最有改进价值的地方
探索新业务模式的可行性
设想新的服务，为每个参与方带来最好的正向结果
设计整洁可维护的事件驱动型（Event-Driven）软件，以支持快速发展的业务
事件风暴的适应性，决定了它允许有不同背景的项目干系人进行复杂的，跨学科的沟通交流，提供了一种跨越信息孤岛和专业界限的新型协作方式。
本质
一套管理复杂软件系统多人协作的步骤和方法，最大可能的让所有人参与表达、专注、思考，促成有效沟通。
在DDD领域中的实践
事件风暴（Event Storming）： 一种基于工作坊的DDD实践方法，可以快速发现业务领域中正在发生的事件，指导领域建模及程序开发。
事件：即事实，即在业务领域中那些已经发生的事件就是事实。
风暴：运用头脑风暴会议进行领域分析建模。
特点：
功能很强大：能够在数小时而不是数周内提出完整业务流程的综合模型。
很有吸引力：整个想法是将提出问题并将知道答案的人带到同一房间，并共同建立一个模型。
容易：符号非常简单。
核心概念
在事件风暴中分为8个核心概念
事件Event
热点Hotspot
决策命令Command
发起命令的参与者User/Actor
外部系统External System
规则Policy
读模型Read Model
聚合Aggregate
事件Event
事件即事实，即在业务领域中那些已经发生的事件就是事实，并可能需要保存下来或者让“别人”响应。
事件是对系统产生了业务上的影响的动作，相对的，如果仅仅是数据查询操作，则只会对系统产生技术上的影响，如CPU上升或者内存上升等。
注意：一般查询操作都不会触发事件的产生，所以查询操作不是事件，如点击了查询按钮显示了数据列表，一般情况下不会有类似于：数据已查询或列表已查询，这样的事件。
事件使用橙色便签表示，并且是过去式，如：用户已注册（User Registered），激活邮件已发送（ActivationEmail Sended）等。
热点Hotspot
热点表示不确定的点、有风险的点或者需要特别注意的点，一般贴在事件旁边，代表这件事情值得特别关注。
热点使用紫色便签表示，文字描述可以随意点，没有格式要求。
决策命令Command
决策命令产生了事件，可理解为产生事件的动作，与事件一一对应。代表行动、意图，命令在领域事件发生之前，表示事件的触发器。如用户已注册（User Registered）事件对应的决策命令就是注册用户（Register User）。
决策命令用正方形蓝色便签表示，在实践中只需要将事件“反过来”就行了。
发起命令的参与者User/Actor
前面的决策命令一定是由某个人或系统来发起的。比如：前面的注册用户这个命令，是由普通用户这个Actor发起的，进而可以联想到可能整个系统中还会有非普通用户，如管理员。
注意：在Big-Picture Event Storming workshop的实践中，不将决策命令贴出来
使用小黄色便签，结合Command和Event。
外部系统External System和规则Policy
Event不一定由前面所说的某个Actor触发Command而产生，也可能是由外部系统或者某种规则自动触发Command而产生。
外部系统使用粉色便签表示。
规则Policy使用紫色便签表示。
读模型Read Model
某个Actor做出决策Command的前提是需要看到某些信息，或者说，支撑Actor更容易做出决策命令Command的信息。读模型一般是通过Web页面（UI/UX）来展示更多的信息，以让用户更容易做出决策。
读模型用绿色便签表示。
聚合Aggregate
某个Actor在某个聚合调用某种Command产生了某个Event。
比如前面的用户已注册（User Registered）事件，是由普通用户（Normal User）在注册薄（Register）上调用注册用户（Register User）这个命令而产生。
聚合使用大黄色便签表示。
整体解释
根据下图中的名字将整体串起来解释下。
一个Actor根据看到的Query Model/Information，决定对External System或者Aggregate执行一个Command/Action，进而产生了某种Domain Event。此Domain Event可能触发了某种Policy，此Policy可能又对External System或者Aggregate执行一个Command/Action。此Domain Event也可能会导致Query Model/Information发生变化，从而给Actor提供更多信息以进行其他操作。
实践形式
事件风暴的灵活性决定了它有多种实践形式，这里主要介绍两种实践形式
Big-Picture Event Storming
What：一种进行业务全景探索的EventStorming形式
Who：产品经理或者开发Leader/架构师作为主持人，市场分析员、业务人员、财务、UX和其他需要配合的部门代表。总人数控制在8-12人。
When：当一个项目或者产品立项之后，并且业务人员（产品人员）已经基本有了项目/产品的构思。
Why：需要和所有的利益相关人（Stakeholders）一起探索发现业务全景，搭建一个平台让Stakeholder能贡献自己的专业知识，让所有人知道全景/边界、风险点、在此项目中的职责并发现产品/项目的逻辑漏洞。
Design-Level Event Storming
What：一种用于更细节的软件设计的EventStorming形式
Who：开发Leader/架构师作为主持人， 业务人员/产品经理，研发团队所有其他人员：测试、前端/后端、UI等。总人数控制在6-12人左右（为减少沟通成本，研发团队不宜过大）。
When：Big-Pic EventStorming之后，产品经理/业务人员自行进行了进一步业务梳理之后，或者某个业务的上下文需要研发团队介入研发之前。
Why：研发团队所有人都需要知道某个上下文的业务全景，需要学习更多的业务知识，以便开始研发工作；研发团队需要进行业务建模、统一业务语言以及知道业务优先级；业务/产品经理需要补充更多关于实现落地的细节，以便进行User Story的补充和优先级的调整。
两种形式的区别
人员
Big-Picture Event Storming侧重在业务方，重点是所有的干系人（StakeHolders），含研发Leader或者架构师
Design-level Event Storming侧重在研发团队内部，含研发Leader或者架构师
目的
Big-Picture Event Storming侧重在探索业务全景，发现热点（风险点或值得特别关注的点），补充不同领域的知识（如财务、运营等），并让stakeholder了解整个项目以及自己在这个项目中的职责（后期需要配合）。
Design-level Event Storming侧重在向研发团队传播业务知识，并进行业务建模，是研发和业务之间沟通的桥梁。
范围
Big-Picture Event Storming侧重在业务全景
Design-level Event Storming侧重在全景中的某个业务上下文
事件风暴能解决的问题
正如本文“实践形式”中描述的那样，事件风暴主要有两种形式用于解决不同的问题。总结来看，它打破了“部门墙”，能让所有人了解到业务的全貌，能让技术和业务在同一个游戏平台上解决真正的问题，能让所有人快速学习业务知识。
当软件系统需要进行跨部门的协作与对齐时，能帮助所有相关人看到整个系统的全貌、让技术和业务在同一个问题上进行讨论、发现有价值的问题、定义与明确各相关人的职责、发现逻辑漏洞、划分系统上下文、统一语言。
当软件系统开始研发之前，能帮助研发团队所有人看到系统的全貌或者一个上下文的全貌、协助进行业务建模，统一语言、非常适合项目研发的kickoff。
当有新人入职时，能帮助新人快速的学习系统的全貌、边界以及统一的语言。
事件风暴不能解决所有问题
不同的沟通形式和方法用于解决不同的问题，事件风暴不可能解决所有沟通问题。
不能解决Why的问题，更适合解决How的问题
事件风暴并不能解决“为什么做”的问题，更适合解决“怎么做”的问题。
一件事做与不做，取决于长期或者短期带来的价值。如对于企业中产品研发来说，一个产品的做与不做，取决于前期的市场调研与分析，有很多工具和方法论用于解决这个问题，比如SWOT、5 Force analysis、BRD，AWS的逆向工作法等。
不适合用做底层技术的讨论
实践证明，事件风暴并不适用于存储系统、API网关、网络通信等底层技术或基础设施的讨论。这些更多需要专业的技术能力，且落地的时候有标准或者最佳实践可以遵循。一般的做法是，架构师或者技术专家进行这些系统的设计，然后跟技术团队沟通并实施，沟通的更多是关于技术人员容易理解的技术上的问题，而不是业务知识。
事件风暴与DDD的关系
一般认为这两者的映射是这样的：
Big-Picture形式的事件风暴的产出对应战略设计中的领域分析，以划分领域边界和限界上下文。
Design-Level形式的事件风暴则继续细化，与DDD的战术设计可以联系起来，可以用来识别聚合根，实体等。
其中统一语言是贯穿始终的！
但两者可以映射起来并不代表他们之间有什么关系，DDD是以强调业务领域为核心的应对复杂业务系统研发的一套方法，而事件风暴只是探索业务领域的其中一种方式（也可以说是工具）。
事件风暴对应事件建模范式，是以事件为视角来观察真实世界，通过事件引起的领域对象状态迁移来驱动出领域模型，进而影响软件实现的整体架构。与之对应的是对象建模范式，是以对象为视角来观察世界，一切皆为对象。而DDD则不关心使用哪种建模范式，只要以业务为核心，对系统进行建模即可，也就是说，事件和对象都可以是业务模型。
事件风暴与头脑风暴的关系
事件风暴和头脑风暴相似但不相同。它们都是多人一起对一件事情进行思考，都有发散和集中的过程，但有以下不同：
目的和产出不同
头脑风暴是大家需要创意的时候，将大家聚在一起进行idea的碰撞。一般产出是几个较好的点子，但并不知道怎么做。
事件风暴强调体系，是业务建模的过程，将大家聚在一起对业务软件系统进行整体（部分上下文）的探索，风险点发现等。一般产出是整块业务系统的模型，所有人完成了知识的交换与学习。
范围不同
头脑风暴的适用范围更广，几乎任何事情都可以大家一起“脑暴”一下。
事件风暴则是明确的面向业务软件研发。
新零售电商中卖家补货参考
新零售电商中批发商城流程参考
.png)
领域模型-子域划分
根据批发商城的整个事件风暴建模总结来看，批发商城分为以下几个域
.png)
核心域
商品域
库存域
订单域
支撑域
购物车域
仓储域
司机域
供应商域
店铺域
通用域
支付域
结算域
优惠券域
计费域
物流域
限界上下文
根据领域划为可以将限界上下文分为以下几个
用户上下文（司机域、供应商域、店铺域）
商品上下文（商品域）
购物车上下文（购物车域）
订单上下文（订单域）
库存上下文（库存域、仓储域）
物流上下文（物流域）
支付上下文（支付域、结算域）
计费上下文（计费域）
营销上下文（优惠券域）
.png)
评论区