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

    作者回复: 不是四色建模。四色建模是通过“时间性实体”“人、地、物实体”“角色实体”和“描述性实体”来建模,有时间再讲讲吧。 你已经把你的游戏软件的事件风暴做出来了,这个要赞一下 事件风暴和用户故事的结合,是一个可行的思路。

    共 2 条评论
    3
  • 超斌hello
    2022-12-14 来自广东
    https://www.processon.com/view/link/639920d07d9c0866853d9d91 试验了一下,技术和业务都听得懂了

    作者回复: 非常棒

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

    作者回复: 看来您已经实践过一段时间,形成了自己的套路

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

    作者回复: 您这篇博客参考了几个不同来源的资料,理解也精到 👍🏻

    共 3 条评论
    5
  • 郭嵩阳
    2022-12-18 来自广东
    事件风暴这些产物要体现在设计文档上吗?应该体现在哪部分?大部分场景下我们拿到的需求都是prd,这部分有些已经很明确了,还需要事件风暴吗

    作者回复: 在下节课都会讨论到

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

    作者回复: 多谢捉虫,事件风暴确实是一种协作的好办法。

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

    作者回复: 笔记记得很详细,学习态度很认真,继续努力!

    
    2
  • 夏
    2023-07-09 来自广东
    基本上一个领域事件只对应一个命令,写了命令就相当于写了事件,把事件和命令都写出来,不是很啰嗦吗?

    作者回复: 是有点啰嗦,也可以只写事件,不写命令。

    
    1
  • 末日,成欢
    2023-08-30 来自陕西
    老师,想要咨询一个问题, 对查询数据/业务规则这里还有点困惑 对于命令来说,可能就是对应的一个API,拿购买商品命令举例 对于查询数据这里, 可能这个领域逻辑需要很多种类的数据,比如【商品信息,活动信息,优惠券信息】 如果还要根据查询出来的商品数据里的一些数据,比如说商品SKU等其他信息, 还要做其他数据的查询, 图里【查询数据】这里就会表示的很多, 或者是业务规则很多的话, 如果一一识别的话, 就感觉过了一遍详细用例,但是感觉不过的话,就怕会遗漏一些场景, 对领域知识理解的不够。 现在的困惑就是我有一个业务流程 业务规则很多, 依赖的数据种类也很多, 有点无从下手。 这是我画的事件风暴,老师可以看下说下问题所在https://www.processon.com/view/link/64ef4046db6e4c759267f88f

    作者回复: 1. 注意,“查询数据”指的是用户通过用户界面查出来,需要看的数据,不是系统内部要查的数据; 2. 找齐业务规则是一个渐进的过程,可以从做事件风暴的时候开始找,不一定全,然后做领域建模时继续找,争取找全,至少在开始编写代码前,一定要找全。找全业务规则,本质上是业务专家的责任,开发人员要和业务专家明确,业务专家没有给出的业务规则,系统是不可能实现的。 3. 关于你的事件风暴,由于不了解你的业务背景,所以不能给出完整的建议。不过,又一个问题,就是你的很多执行者都是“系统”,不知为什么,感觉其中很多应该是具有一定角色的人。比如说新增黑名单,应该是某种操作员来增加的。

    
    
  • aoe
    2023-07-25 来自浙江
    第二次学习「事件风暴」,关于「识别领域名词」,按自己的理解整理了一下: 第一步:把围绕同一个名词(相同/相关名词)的「领域事件」放在一起,按「名词」分组 第二步:将「领域事件」对应的「命令」、「查询数据」加入分组 第三步:将「领域名词」加入分组 详见 https://wyyl1.com/post/23/07/

    作者回复: 这学习精神,棒棒哒!

    
    