1.用例和用户故事更独立细致，是垂直视角对需求的提炼。产物更详细，耗时更长； 事件风暴则比较像水平视角对需求的提炼，重心在快速了解核心业务，识别核心领域名词，粒度更粗，但广度更广，耗时相对短很多。主要也是为后续沟通的开展建立基础。 如果领域名词比较多，且关系复杂，就很有必要在项目前期做一轮事件风暴，拉齐基础认知。 2.事件风暴会去识别规则吗？ 我一般不做，规则在后续，通过用户故事来补齐。主要是事件风暴时间线在前期，对规则容易陷入细节，不好把握会议节奏。所以更多的是仅串主流程，识别核心领域名词。 3.事件风暴仅罗列“主流程”吗？我一般不限制，因为在开事件风暴的时候，我脑子里的“主流程”大概率只是一厢情愿。我们都知道有隐式概念，隐式，表达的是知识归宿的特殊性。可能只有圈内人懂，可能只有那么几个人甚至一个人脑子里才有。隐式概念的显式化靠的是业务专家几年几十年的积累，而不是一场事件风暴。而一厢情愿的“主流程”容易漏掉这些关键概念，所以我一般是简单引导 + 不断追问是否有补充，尽量收集信息。后续自己过滤一遍，然后与专家再碰，达成一致。 4.记录事件风暴时，带命令和执行者吗？ 我不带，一方面时间不够（时间问题可以通过工作坊形式的调整来满足），另一方面给自己做后续分析时埋思考的机会。只要事后补执行者和命令，就一定会有模糊的点，这些都是展开思考和后续沟通对齐的点。

2w2h笔记 why what 事件风暴步骤回顾 识别领域事件。 识别命令和角色以及相关查询数据。 识别领域名词。（从命令、角色、事件中提取对事件有影响的名词） 命令是什么？ 产生业务结果的动作，可以从领域事件中倒推出来。 签订合同（命令）-> 合同已签订（领域事件） 角色是什么？ 发起动作的对象就是所谓的角色。 例如：客户（角色） -> 签订合同（命令）-> 合同已签订（领域事件） 查询数据是什么？ 要使角色完成动作所需要的最少必要数据。 例如：上述示例需要客户和合同信息才能完成。 事件风暴中不同元素在建模和实现层面都有什么作用？ TODO 常见问题 第一个问题是，在事件风暴里是否要列出所有的领域事件和命令？ 否，列出当前最为关注的内容。这一步关注的是全面，较为粗粒度的结果。 细化的部分放到后面进行。 第二个问题是，各个领域事件需要体现严格的时间顺序吗？ 细节放在其它环节 第三个问题是，每个步骤的颗粒度应该有多大？ 宜粗不宜细，保证每个步骤都在一个层次的粗粒度。 第四个问题是，事件风暴适用于所有项目吗？ 它要解决的问题是需求与业务的一致等问题，只要需要解决这个问题，就可以用。 第五个问题是，怎么保存和维护事件风暴的结果？ 1、如果需求管理有其它手段代替的话（用户故事、用例等），则可以把它当做临时结果。 2、如果没有的话，就持续维护它。 how Q: 识别命令和角色以及相关查询数据? A: 理解相关概念，然后用不同的便利贴来体现。 Q: 如何进行识别领域名词？ 1、识别出角色、命令、查询数据、领域事件中的名词性概念。 2、把围绕同一名词的角色、命令、查询数据、领域事件放在一堆。 3、此时该名词已是领域名词。只需将其做个特殊标识，便于区分。 Q: 一个名词在事件和命令中都出现如何标识？ 该名词后给个出现次数的数字即可。 how good --- 思考题： 1、如果你以前学习过用例分析、用户故事等方法，那么比较一下，看它们和事件风暴各自有什么优缺点？ 两者实践不多，直观感受是事件风暴的文字量极少，图形展示比较直观。其它两种可能就对文字描述更为依赖。 2、如果你自己的项目中，已经有捕获行为需求的方法，那么怎样借鉴事件风暴的思路，为现有的方法添加协作和统一语言的实践？ 统一语言的话，需求梳理过程中强调命名的统一，加个术语表。 协助过程优化TODO。