专栏名称: 逸言
文学与软件,诗意地想念。
目录
相关文章推荐
程序员的那些事  ·  趣图:我和 DeepSeek 互换角色 ·  昨天  
OSC开源社区  ·  2024年中国开源模型:崛起与变革 ·  昨天  
码农翻身  ·  漫画 | ... ·  23 小时前  
程序猿  ·  450万虚假Star曝光,最低0.7元/个? ... ·  3 天前  
程序员的那些事  ·  热搜第一!DeepSeek百万年薪招AI人才 ... ·  3 天前  
51好读  ›  专栏  ›  逸言

事件风暴过程全体验-上篇

逸言  · 公众号  · 程序员  · 2019-12-09 11:55

正文


| 逸派胡言


ThoughtWorks 钱平

作为TW技术咨询师,为多家企业进行架构和 Fintech 创新相关技术咨询,如架构设计、遗留系统上云迁移及规划、各种技术赋能、企业技术相关平台的生态规划及落地建设,创新实验室的技术部分筹建等等。 此前,10多年的投行研发经验,包括外汇交易等核心系统,涉猎从架构、开发、Scrum Master、运维等多个角色。 个人创业经验经历涉及互联网、金融和教育行业,并在广州多所重点大中院校担任创客导师。


又一年的DDD-China大会,碰上北京的初雪,这次终于没有因为太干燥而病倒了。


今年在大会的互动区给大家准备了一个事件风暴的小体验,参加了的小伙伴说“很爽”,那这里就把这个小案例分享一下,让更多人来一起爽 ^_^



故事背景


场景源于一个打劫案件,当劫匪拿出他的枪,来自未来的超能摄像头发现危险马上自动报警。 同时,各位正义英雄暗地里开始出动!

哪知道这班劫匪也不是盖的,某正义英雄(请自动脑补蝙蝠侠)虽然第一个到场,和劫匪激战一轮居然也还没拿下,无奈中只能触发身上的升级预警装置通知总部增援。


总部系统收到通知马上召集了其他英雄线上会议商讨对策,作战计划一出,第二批英雄马上抵达现场,几经周折终于把劫匪抓获。


这里用一个简化版的用户旅程地图描述了这个场景。 通常地,类似的用户旅程就正是掀起事件风暴的优秀开端~


现在让我们假设,作为英雄总部,我们计划基于这个场景构建一个自动预警系统,从而让整个预警过程更加智能更加顺畅,那我们IT民工该怎么和总部一起设计这个系统呢?


事件风暴-拉开序幕


当开启事件风暴,第一件事情是必须把自己的视角切换到自动预警系统的设计师这个角色上来,谨记,我们关注的是这个系统在这个场景下应该怎么运作,系统以外的细节我们可以暂且忽略。 换而言之,“自动预警”就应该是核心域。


在正统的事件风暴过程中:

  • 第一步就是寻找事件并以“XX已YY”(如“订单已提交”)完成时态描述这个事件

  • 第二步就是寻找这个事件对应的命令,通常是一个动宾结构(如“提交订单”)


而在这里,对于不太复杂的系统我会倾向与合二为一,同时去列举出“角色/读模型/命令/事件”。 这里举一个🌰说明一下“角色/读模型/命令/事件”分别是什么:

  • 角色 简单来说就是主语,可以是人物,可以是类似于定时任务的规则,可以是外部系统

  • 读模型 (Optional)角色是基于什么信息做之后的决定的,不一定每步都有

  • 决策/命令 原译Command,但叫“业务决策”可能更好理解,反正就是描述做了什么决定

  • 事件 描述之前的决定触发了什么事情,或者说决策导致某东西的状态变了为什么。



当然,如果在做的过程中发现这样连起来想不清楚,那就还原基本步,按照原来的事件->命令这样小步走就好了.


Step 1. 命令风暴


下面是我自己设计的命令风暴,结果跟大家在互动区设计的还是差不多的。 (我这个贴法跟正宗的有点不一样,主要是为了糊墙的时候省地方)



这个并不是标准答案,而且也并不存在标准答案。 因为我们是在设计,一百个人就有一百个哈姆雷特,按团队商量统一一个思路走就可以了。


再列几个在这过程中常见的疑问:


在我的风暴中,会议商量出来的叫“作战计划”,现场童鞋商量出来的是“抓捕计划”,这个就是传说中的统一语言的过程,只要得到一个团队一致认可的名字就可以了。


风暴中,有“预警通知”、“警报”、“升级预警通知”,有童鞋会问是不是可以统一叫“通知”,这个其实也是统一语言和对业务的理解问题,如果觉得三个场景都是发送一样的通知就可以了,那统一叫“预警通知”是个不错的选择,但如果希望每次发送的内容都不一样,那还是得取个不一样的名字方便后续辨认区分。


现场童鞋曾经出现一个场景写到“英雄->登出会议->会议已结束”。 这里会考虑登出和结束之间是不是漏了一些步骤,因为按套路走的话应该是“登出会议->会议已登出“,”结束会议->会议已结束“。 现在写的决策和事件并不对应,可见应该有遗漏。


过程中,比如开会怎么商量,作战计划怎么执行,这些其实不是这个预警系统关注的事情,所以不需要进一步展开.


Step 2. 识别业务对象


简单来说,就是要找出之前那个”决策/命令“打算要操作什么东西? 或者说那个“事件”里面“XX已YY“的XX说的是什么。



如果第一步是严格按照“XX已YY”的写法进行,这里应该难度不是特别大。


当然,如果在第一步里面把一些查询或者打开页面这类的动作也放进命令风暴的话,有可能那些步骤会找不出一个业务对象,或者就成为“XX页面”。 这也是为什么通常在命令风暴中不考虑一些查询动作的原因,打开页面的动作并没有实际改变什么东西的状态。


Step3. 分析业务对象生命周期


在通常的事件风暴介绍中,“分析生命周期”经常就是一句话带过,但这里我会建议大家显式地把生命周期画出来,这样对于后续分辨聚合根/实体/值对象会很有帮助。


有一些信息只出现了一次,所以画出来就成了一个点,明显的这些可以先归为值对象,因为他们只是某个值,而没有生命周期,不需要id之类的标识。


另一类是一条线段,可见他们是有生命周期的,期间是带有状态的,这些就是传说中的实体了。


那哪些是聚合根呢?

  • 简单来看,就是看这些点和线的归属。







请到「今天看啥」查看全文