04｜事件风暴（下）：事件风暴还有哪些诀窍？

这里是四色建模法么？ 识别领域事件：场景已创建、策略已创建、任务已创建、装备已选择、目标已标定、玩家已选定（红蓝白） 识别命令：创建场景、创建任务、选择目标、设置毁伤、创建装备、创建想定、创建兵力 识别领域名词：场景、任务、装备、模型、目标 对于思考题： 之前接触过用户故事，感觉用户故事可以把系统的功能串联在一起，更加场景化一些；而事件风暴感觉有点类似于头脑风暴的过程，相对发散一些。比较好的方法可能是先采用事件风暴发散，找到足够多的领域事件，然后使用用例分析或者用户故事将领域时间串联在一起。 如果借鉴事件风暴的思路，那么可能首先需要和业务人员同步一下对于业务中各个概念的定义，形成一个团队内部的术语表。曾经在业务讨论中，出现过多次业务术语不一致的情况。从这个角度来说，事件风暴其实也是一次很好的统一语言的方式。

https://www.processon.com/view/link/639920d07d9c0866853d9d91 试验了一下，技术和业务都听得懂了

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

这样看来事件风暴抓准了企业软件开发中协作困难这个痛点，以事件为核心允许不同背景的利益相关方展开对话，并超越各自的专业背景界限，借助白板便利贴重视头脑风暴的可视化，尽可能让所有参与者充分咀嚼领域知识，从而深刻高效地挖掘与传递业务知识，形成业务全景图，减少信息孤岛等偏差存在，有效降低复杂软件的需求分析与传递成本。 做了个2000字小笔记，对事件风暴的粗浅认知：https://juejin.cn/post/7182111319967924282

事件风暴这些产物要体现在设计文档上吗？应该体现在哪部分？大部分场景下我们拿到的需求都是prd,这部分有些已经很明确了,还需要事件风暴吗

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

抓个虫，最后一幅图中 R001的“举例“和R005的举例重复了，应该体现不同项目之间分配投入时间比例不超过100% 我认为事件风暴建模法比传统方法更敏捷高效，强调协作，三下五除二就把主要业务流程建模出来了，不用一上来就陷入不必要细节，而且和领域驱动设计是天生一对

基本上一个领域事件只对应一个命令，写了命令就相当于写了事件，把事件和命令都写出来，不是很啰嗦吗？

看了05、06领域建模又回来看这两讲事件风暴，重新理解了下，感觉事件风暴就是两个核心作用：对齐理解、统一语言。事件风暴对建模的帮助像是这两核心功能顺带的，而建模不必依赖事件风暴。

1.用例分析感觉颗粒度比较大，并不能很好的提取出领域事件、领域模型，会比较粗粒度的从用户交互出发；用户故事这个没有用过 2.统一语言应该是业务、产品、开发对齐一致的结果，从需求梳理到最后一致的表达，刻画在模型上