1.事件风暴第二步：识别命令
比如说，对于“合同已签订”这个事件，对应的命令就是“签订合同”。 1)“签订合同”这个操作是什么人执行的呢？需求里说是“销售人员”。这里的销售人员术语上叫做“执行者”，英文是 actor。
2)为了表示执行者是人，这里还在便利贴上画了一个小人儿。
3)“客户”是一种“查询数据”。我们把查询数据写在小一点的绿色便利贴上，也贴在命令上方
相对完整的事件风暴图如下：
2.事件风暴第三步：识别领域名词
识别领域名词的操作步骤可以分成两小步。
1）把围绕同一个名词的命令、事件、执行者、查询数据摆在一起
2）把领域名词写在大一点的黄色便利贴上，贴在每堆便利贴的中间
最终形成如下领域名称专题图：
常见问题：
1）相互关联的领域名称，会出现重复事件。如“为项目分配员工”和“员工已分配”
- 有些名词没有添加这类动作
通过识别命令和领域名词这两个步骤，就完成了事件风暴的所有动作。
3.总结
3.1关于事件风暴几个部分的说明
1）领域事件的作用：领域事件一般会对应一段代码逻辑，这段逻辑可能会最终改变数据库中的数据
2）命令：在实现层面，一个命令可能对应前端的一个操作，例如按下按钮；对于后端而言，一个命令可能对应一个 API。
3）命令的执行者： 在领域建模时，执行者可能本身就是一个领域对象，也可能是领域对象充当的角色，或者是权限管理中的一个角色。
4）查询数据：查询数据是为了某个命令服务的。系统中可能还有一些单纯的查询功能，并不与某个特定的命令绑定。
5）领域名词：最终目的是要找到领域模型中的对象
3.2常见问题
3.2.1在事件风暴里是否要列出所有的领域事件和命令
建议：在事件风暴里只列出主要的、足以用于表达和交流领域知识的步骤
3.2.2各个领域事件需要体现严格的时间顺序吗
应该关注点分离。如果要体现严格的时间顺序，我们可以用流程图、用顺序图等方法，但事件风暴不必关注这一点。
3.2.3每个步骤的颗粒度应该有多大
原则上宜粗不宜细。可以先采用比较大的颗粒度。后面必要的时候，再拆细
3.2.4事件风暴适用于什么项目
第一个层面，事件风暴主要应用在需求不清晰，或者理解不统一的情况下，通过协作的方式理清业务、达成一致，所以通常对于新项目比较适用。 至于遗留系统改造的情况，如果这个系统的知识已经流失得很严重，那么事件风暴仍然是有意义的。但如果大家对这个系统的业务知识很清楚，只是要进行架构改造，那么事件风暴的意义就不大了。
第二个层面，即便在适用的场合，事件风暴也不是唯一的方法，我们还可以用用例分析、用户故事等方法实现类似的目的。只要抓住协作、统一语言等等要点，这些方法都可以用在 DDD 的项目里。
3.2.5怎么保存和维护事件风暴的结果
专门安排一个记录员进行电子化。 除了绘图之外，事件风暴也可以用表格的形式来保存
3.2.6怎么保存领域规则
领域规则是重要的领域知识，必须妥善保存。
例子如下：
4.观点
1）事件风暴抓准了企业软件开发中协作困难这个痛点， 以事件为核心允许不同背景的利益相关方展开对话，并超越各自的专业背景界限， 借助白板便利贴重视头脑风暴的可视化， 尽可能让所有参与者充分咀嚼领域知识， 从而深刻高效地挖掘与传递业务知识，形成业务全景图，减少信息孤岛等偏差存在， 有效降低复杂软件的需求分析与传递成本。
2）用例分析和事件风暴，本质上都是谁做了什么事情，系统如何进行处理；用例分析会更贴近业务需求，描述的是具体的业务场景，离技术比较远；事件风暴侧重于业务和技术的融合，不仅描述业务也指导技术建模；
5.事件风暴案例分享
www.processon.com/view/link/6…
学习来源：钟敬的《手把手教你落地 DDD》
