事件风暴
为什么引入事件风暴:
从经典之作《领域驱动设计》以及领域驱动资源研究者了解到,事件风暴之一的作用就是拉通业务方、产品、研发、测试对业务知识的统一理解,避免各方理解误差。但在实际操作中受限于各方时间协调的难度及领域专家的角色的缺失,事件风暴往往作为理解业务,领域建模及领域划分的利器去使用。
什么是事件风暴:
事件风暴是一种以工作坊的方式对复杂业务领域进行探索的高效协作方法,事件风暴强调以事件驱动团队探索分析业务领域。
- 一种捕获行为需求的方法
- 强调以先发散后收敛的方式开展
- 相关干系人协作的方式进行
- 注重对领域事件的识别
事件风暴相关元素:
1.事件(橙色):重要且已发生的事情。命名方式:完成时+被动语态=宾语+动词过去式
2.命令(蓝色):产生事件触发的动作
3.角色/执行者:触发命令的主体,包括:人员(浅黄色)、系统(红色)、定时任务(绿色)
4.读模型:执行者决策执行命令时参考的视图元素
5.写模型:状态发生变化的对象,真实因为对象发生了变化才导致事件的发生
事件风暴准备工作:
1.业务相关干系人
2.贴纸
3.事件风暴主导人
事件风暴操作流程:
我们以大家非常熟悉的骑行共享单车为例,进行事件风暴的演练
1.识别重要事件
2.识别命令
3.识别执行者和读模型
4.识别领域对象
领域对象识别的方法:
- 识别命令和事件中的名称,这些名称就对应初步识别的领域对象
- 根据名词对命令和事件进行重排序,作用于同样名词的时间和对象放到一起
- 作用于的名称就可以作为领域对象
领域对象就不进行贴图,分为2大领域对象:用车、申诉单
5.根据领域对象进行领域划分
从上图可以看到,用车域过于庞大,是否可以继续拆分,这是我们有两种依据进行拆分:1.识别关键事件以此作为拆分的节点,2、识别事件的紧密关系程度
我们依据此两个标准进行分析,扫码是关键的时间节点,扫码后用户可以进行用车了,同时扫码和后续的事件有紧密的关系,不扫码无法进行后续的操作,那么我们进行进一步的拆分,拆分为三个领域,如下图:
6.引入写模型进行领域划分
在第5步,根据领域对象进行领域划分时我们遇到一个问题点就是用车的领域过于庞大,我们依据重要事件节点和事件紧密程度进一步划分,但是过于依赖经验和专家意见,有没有一种比较客观的方式呢,有,就是引入写模型,写模型基于现实单据和职责的角度去进行分析,思路清晰更加清晰。
如下图:预约命令基于预约单进行业务处理,那其归属预约域。扫码、确认开锁、确认还车基于行程单,那么归属行程域。车费申诉基于申诉单,归属申诉域。
还车检查不会改变行程状态,且是无状态的,或者说我们暂时未识别到对应的写模型,那么我们作为一个策略域单独维护。
事件风暴为什么有效:
事件风暴以事件作为驱动,源于事件意味一种因果关系的推断,更符合人类的思考习惯,同时干系人各方都参与进去,可以从各个维度进行全面的分析。
----------------------
todo:
事件风暴中各个元素的作用,为什么引入这些元素