作为TW技术咨询师,为多家企业进行架构和 Fintech 创新相关技术咨询,如架构设计、遗留系统上云迁移及规划、各种技术赋能、企业技术相关平台的生态规划及落地建设,创新实验室的技术部分筹建等等。此前,10多年的投行研发经验,包括外汇交易等核心系统,涉猎从架构、开发、Scrum Master、运维等多个角色。个人创业经验经历涉及互联网、金融和教育行业,并在广州多所重点大中院校担任创客导师。
又一年的DDD-China大会,碰上北京的初雪,这次终于没有因为太干燥而病倒了。
今年在大会的互动区给大家准备了一个事件风暴的小体验,参加了的小伙伴说“很爽”,那这里就把这个小案例分享一下,让更多人来一起爽 ^_^
故事背景
场景源于一个打劫案件,当劫匪拿出他的枪,来自未来的超能摄像头发现危险马上自动报警。同时,各位正义英雄暗地里开始出动!
哪知道这班劫匪也不是盖的,某正义英雄(请自动脑补蝙蝠侠)虽然第一个到场,和劫匪激战一轮居然也还没拿下,无奈中只能触发身上的升级预警装置通知总部增援。
总部系统收到通知马上召集了其他英雄线上会议商讨对策,作战计划一出,第二批英雄马上抵达现场,几经周折终于把劫匪抓获。
这里用一个简化版的用户旅程地图描述了这个场景。通常地,类似的用户旅程就正是掀起事件风暴的优秀开端~
现在让我们假设,作为英雄总部,我们计划基于这个场景构建一个自动预警系统,从而让整个预警过程更加智能更加顺畅,那我们IT民工该怎么和总部一起设计这个系统呢?
事件风暴-拉开序幕
当开启事件风暴,第一件事情是必须把自己的视角切换到自动预警系统的设计师这个角色上来,谨记,我们关注的是这个系统在这个场景下应该怎么运作,系统以外的细节我们可以暂且忽略。换而言之,“自动预警”就应该是核心域。
在正统的事件风暴过程中:
而在这里,对于不太复杂的系统我会倾向与合二为一,同时去列举出“角色/读模型/命令/事件”。这里举一个?说明一下“角色/读模型/命令/事件”分别是什么:
当然,如果在做的过程中发现这样连起来想不清楚,那就还原基本步,按照原来的事件->命令这样小步走就好了.
Step 1. 命令风暴
下面是我自己设计的命令风暴,结果跟大家在互动区设计的还是差不多的。(我这个贴法跟正宗的有点不一样,主要是为了糊墙的时候省地方)
这个并不是标准答案,而且也并不存在标准答案。因为我们是在设计,一百个人就有一百个哈姆雷特,按团队商量统一一个思路走就可以了。
再列几个在这过程中常见的疑问:
在我的风暴中,会议商量出来的叫“作战计划”,现场童鞋商量出来的是“抓捕计划”,这个就是传说中的统一语言的过程,只要得到一个团队一致认可的名字就可以了。
风暴中,有“预警通知”、“警报”、“升级预警通知”,有童鞋会问是不是可以统一叫“通知”,这个其实也是统一语言和对业务的理解问题,如果觉得三个场景都是发送一样的通知就可以了,那统一叫“预警通知”是个不错的选择,但如果希望每次发送的内容都不一样,那还是得取个不一样的名字方便后续辨认区分。
现场童鞋曾经出现一个场景写到“英雄->登出会议->会议已结束”。这里会考虑登出和结束之间是不是漏了一些步骤,因为按套路走的话应该是“登出会议->会议已登出“,”结束会议->会议已结束“。现在写的决策和事件并不对应,可见应该有遗漏。
过程中,比如开会怎么商量,作战计划怎么执行,这些其实不是这个预警系统关注的事情,所以不需要进一步展开.
Step 2. 识别业务对象
简单来说,就是要找出之前那个”决策/命令“打算要操作什么东西?或者说那个“事件”里面“XX已YY“的XX说的是什么。
如果第一步是严格按照“XX已YY”的写法进行,这里应该难度不是特别大。
当然,如果在第一步里面把一些查询或者打开页面这类的动作也放进命令风暴的话,有可能那些步骤会找不出一个业务对象,或者就成为“XX页面”。这也是为什么通常在命令风暴中不考虑一些查询动作的原因,打开页面的动作并没有实际改变什么东西的状态。
Step3. 分析业务对象生命周期
在通常的事件风暴介绍中,“分析生命周期”经常就是一句话带过,但这里我会建议大家显式地把生命周期画出来,这样对于后续分辨聚合根/实体/值对象会很有帮助。
有一些信息只出现了一次,所以画出来就成了一个点,明显的这些可以先归为值对象,因为他们只是某个值,而没有生命周期,不需要id之类的标识。
另一类是一条线段,可见他们是有生命周期的,期间是带有状态的,这些就是传说中的实体了。
那哪些是聚合根呢?
所以,看生命周期还得全面的看,在集合了多个场景之后才会比较准确。当然,里面也会有一些业务常识在,比如“会议”如果一开始我们就选择了Zoom之类的外部系统实现,那很明显它就应该独立出去自己聚合了。
Step4.
这里第四步包括了两部分:聚合细化 & 上下文分析,这两部分其实是相辅相成的,并没有绝对的顺序,有时候还会根据其中一步的分析结果来回调整另一步,所以这里我把它们归到一起。
Step4a. 细化聚合根分析
这里我们先假设,会议有其他场景也用到,所以它属于另一个聚合。
那下面我们就可以把上面的业务对象按照聚合的方式细化分析他们之间的关系了。并可以补充上一些关键的属性
Step4b. 识别上下文和调用关系
同理也可以划分出上下文以及他们之间的调用关系。(这里的U我是指消费者/调用方,而D是生产者/被调用方)
留意,这里说的是上下文,也就是业务边界,它跟服务划分并没有绝对的关系。
要问如果对应到服务划分,其实我们还得多看几个维度综合考虑,比如:
至此,从用户旅程的一个场景,到业务领域的划分就完成了 ^_^