DDD的事件风暴第二个阶段“业务场景分析”是从用户视角出发的，根据业务流程或用户旅程，采用用例和场景分析，探索领域中的典型场景，找出领域事件、实体和命令等领域对象，支撑领域建模。
事件风暴参与者要尽可能地遍历所有业务细节，充分发表意见，不要遗漏业务要点。
本阶段的
- 输入： 上阶段的服务价值定位：DDD事件风暴 - 产品愿景阶段
- 产出物：场景分类清单
图例说明
我们用下面四种帖纸来代表不同类型的信息。
事件（Event）
事件是对已发生事实的陈述（比如：股票已购买、请假单已创建...）。换句话说，一个事件集是指系统中已经发生的一些历史记录。事件一般用过去时态来表达。
一般来说，事件风暴会议启动后，参与者都开始往墙上贴事件 —— 任何有趣的，值得讨论的事件：
事件是一个系统天然的基础，因为它们是业务流程最贴切的表示法，能围绕它们和主题专家展开讨论。
命令（Command）
命令通常是一个或多个事件序列的触发器。事件代表着过去不可改变的事实，而命令用来表达让事情在未来发生的意图。
命令可以被驳回。比如，由于客户投资组合中没有足够的股份，导致“卖出股票”这个命令被驳回，
- 命令通常用现在时态来表示，而事件总是过去时态。
- Event 代表事实，是不可逆的，这个从一般命名也可以看出来：OrderCanceledEvent；
- Command 代表意向，还未发生，命名一般是：CancelOrderCommand；
- 某Command执行的结果可能导致若干Event的发布；
业务流 和 补充说明
业务流也就是业务流程，是我们串起整个业务的主线，这里的目的是为了要尽可能地遍历所有业务细节，不要遗漏业务要点。
补充信息主要用来说明注意事项，比如外部依赖等。
请假业务场景分析
以请假和审批为例：
- 请假的用户（角色）为请假人，
- 审批的用户（角色）为审批人。
作为请假人，其用户旅程为：
- 登录系统，从鉴权中心获取请假人信息和权限数据，完成登录认证；
- 创建请假单：在请假页面选择请假类型、起始时间，录入请假休息，保存请假单；
- 修改请假单：查询请假单，修改、保存；
- 提交审批：将创建的请假单提交审批，系统会获取审批规则，并根据审批规则，从人员组织关系中获取审批人，给请假单分配审批人。
作为审批人，其用户旅程为：
- 登录系统，从鉴权中心获取请假人信息和权限数据，完成登录认证；
- 获取请假单：获取审批人名下的请假单；
- 审批：填写审批意见，批准或者拒绝；
- 逐级审批：审批人批准请假单后，系统会根据审批规则判断是否需要继续审批；
- 完成审批：系统发出领域事件：请假单已审批通过，后续会进一步执行邮件通知请假人、将请假数据发送到考勤的操作。
“根据审批规则查询审批人”需要依赖另一个上下文：人员组织关系，它的场景分析如下：
用户中台 业务场景分析
用户中台有这样三个典型的业务场景：
- 第一个是系统和岗位设置，设置系统中岗位的菜单权限；
- 第二个是用户权限配置，为用户建立账户和密码，设置用户岗位；
- 第三个是用户登录系统和权限校验，生成用户登录和操作日志。
我们可以按照业务流程，一步一步搜寻用户业务流程中的关键领域事件，比如岗位已创建，用户已创建等事件。
再找出什么行为会引起这些领域事件，这些行为可能是一个或若干个命令组合在一起产生的，比如创建用户时，第一个命令是从公司HR系统中获取用户信息，第二个命令是根据HR的员工信息在用户中台创建用户，创建完用户后就会产生用户已创建的领域事件。
当然这个领域事件可能会触发下一步的操作，比如发布到邮件系统通知用户已创建，但也可能到此就结束了，你需要根据具体情况来分析是否还有下一步的操作。
组织业务场景分析的技巧
会议时间控制
不可能不限时的寻找，可以用下面的方式来组织会议。
- 所有的参与人在10分钟内尽可能的写出可能想到的领域事件
- 时间结束后，参与人把自己的领域事件便签添加到“公屏”上
- 主持人和所有参与人一起去掉重复的事件，然后对剩下的领域事件标签按照时间线排序
有疑问时标记下，跳过
在遇到有疑惑的事件时，不必长时间阻塞在那里讨论，把它作为标记记下来即可，后续再进行重点优化。可以贴一个比较醒目的便签纸（比如紫色）在事件旁边。
随着我们对业务认识的不断加深，可以随时回顾和总结之前添加的内容，对于有问题的描述进行更正，对于表述不清楚的内容可以进行重写。
事件的粒度？
我们在讨论这个问题之前，首先要思考事件是什么。事件是领域专家关心的业务事件。所以它不能比领域专家关心的业务更细，因为那将毫无意义。
举个例子：如果我们关心的是一个人一天的作息，那我们可能关心的是用户已起床，用户已吃早餐，用户已上班。
但我们不会关心到更细节，比如：用户已睁眼，用户已洗漱，用户已出门，用户已上地铁……
同时，事件粒度也不能太粗，因为太粗粒度的事件不利于寻找领域模型。
比如我们在平台上发一篇文章的业务。如果你只写一个“文章已发布”，那就可能会丢失掉一些比较重要的业务流程。
尝试改成：文章已保存，文章已申请审核，文章已通过审核，文章已审核失败，文章已对外发表，文章已加入分类，文章已推荐……
你会发现，中间多了一个审核的过程，如果不找到这些命令，就很有可能遗漏掉“文章审核单”之类的模型。
对某个事件有歧义
这是好事情，说明你们团队需要讨论了，有时还可以发掘出原本可能没有注意到的业务细节。
但在实施事件风暴的时候，不必刚开始就花太多的时间在上面，阻塞了后面的事件发掘。
而是应该先前面说的那样，用一个醒目的标记记下来，后面再回过头来充分讨论。
或许最开始有歧义的地方，在事件逐渐完善，领域模型定义出来后，就没有歧义了。
一个命令产生多个连锁事件
这个是正常的，一个命令可能会触发一个事件或者多个事件。
也有可能一个事件触发了另一个事件，只需要把它们贴在一起即可。
