学习
实践
活动
工具
TVP
写文章
专栏首页斑斓事件风暴过程全体验-上篇

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

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之类的标识。

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

那哪些是聚合根呢?

  • 简单来看,就是看这些点和线的归属。比如上图中,“案件记录”的生命周期是最长的,也包含了其他所有的业务对象生命周期,那看起来它就应该是聚合根。
  • 再看“警报升级会议”,看起来没有案件就没有它的存在,所以它应该是属于“案件记录”这个聚合根里面的一个实体,但如果我们扩展一下分析的场景,比如假设有另外一个场景是说在平常其实英雄也需要开例会,而且对应的也是一样的创建/登入/登出/结束,我们觉得它们可以统一处理,那这样“会议”就会是另外一个聚合
  • 同理,“警报升级通知“等的三个值对象,如果只在案件周期内存在,那他们就是隶属于案件的值对象。但如果我们有其他场景是会比如配置这些通知的不同模版的, 那这些通知就有了自己的生命周期,可能自己会独立成为聚合根

所以,看生命周期还得全面的看,在集合了多个场景之后才会比较准确。当然,里面也会有一些业务常识在,比如“会议”如果一开始我们就选择了Zoom之类的外部系统实现,那很明显它就应该独立出去自己聚合了。

Step4.

这里第四步包括了两部分:聚合细化 & 上下文分析,这两部分其实是相辅相成的,并没有绝对的顺序,有时候还会根据其中一步的分析结果来回调整另一步,所以这里我把它们归到一起。

Step4a. 细化聚合根分析

这里我们先假设,会议有其他场景也用到,所以它属于另一个聚合。

那下面我们就可以把上面的业务对象按照聚合的方式细化分析他们之间的关系了。并可以补充上一些关键的属性

Step4b. 识别上下文和调用关系

同理也可以划分出上下文以及他们之间的调用关系。(这里的U我是指消费者/调用方,而D是生产者/被调用方)

留意,这里说的是上下文,也就是业务边界,它跟服务划分并没有绝对的关系。

要问如果对应到服务划分,其实我们还得多看几个维度综合考虑,比如:

  • 组织架构(康威定律)- 比如上面预警系统如果都是一个团队管,那会议和案件不太复杂的时候放在一个服务也不是不可以,但如果分别两个团队管,那还是分开好,免得吵架。
  • 业务边界(上下文)
  • 变更频率 - 比如营销活动上下文里面有营销活动的规则,活动的元素基本固定,但活动规则经常变,这样我们可以考虑从活动上下文中再分出活动规则
  • 高并发、低延时等的非功能性需求 - 比如某些高并发场景需要读写分离,那就会把一个上下文再拆开读和写两部分
  • 技术层面需求 - 比如因某些特性需要用不同的语言编写
  • 安全等其他层面要求

至此,从用户旅程的一个场景,到业务领域的划分就完成了 ^_^

文章分享自微信公众号:
逸言

本文参与 腾讯云自媒体分享计划 ,欢迎热爱写作的你一起参与!

作者:钱平
原始发表时间:2019-12-09
如有侵权,请联系 cloudcommunity@tencent.com 删除。
登录 后参与评论
0 条评论

相关文章

  • 事件风暴过程全体验-下篇

    作为TW技术咨询师,为多家企业进行架构和 Fintech 创新相关技术咨询,如架构设计、遗留系统上云迁移及规划、各种技术赋能、企业技术相关平台的生态规划及落地建...

    张逸
  • 事件风暴的设计要素与驱动力

    个人认为,相比较传统领域分析方法,事件风暴的革命意义在于它建立了以“领域事件”为核心的建模思路,这相当于改变了我们观察业务领域的世界观。

    张逸
  • 运用事件风暴进行领域分析建模

    本文是事件风暴方法的第二部分,从获得的业务全景开始进行领域分析建模,通过事件识别出决策命令,进而驱动出读模型和聚合。获得领域分析模型还将是领域驱动设计过程的重要...

    张逸
  • 全栈设计+编程的方法论,以“猜对联”小程序为例

    趁着快过年,花了 2 天晚上从设计到开发,做了一款小程序 “ 猜对联 ” ,可以用于公众号吸粉,也可以朋友间拜年,也可以作为聚会的真心话大冒险游戏,玩法多样,全...

    mixlab
  • 领域驱动实践总结(基本理论总结与分析+架构分析与代码设计+具体应用设计分析V)[通俗易懂]

    领域驱动设计DDD是一种设计思想,它可以同时指导中台业务建模和微服务设计(中台本质是业务模型,微服务是业务模型的系统落地),领域驱动设计强调领域模型和微服务设计...

    全栈程序员站长
  • 识别领域事件 | 洞见

    随着微服务架构的兴起,微服务设计与拆分的的最佳实践DDD已然成为大家讨论与实践的热点,整个行业都在探索如何用DDD建模来实现微服务设计。事件风暴作为最接地气的实...

    ThoughtWorks
  • 体系化文档化数字化管理学习暨2019个人年度总结

    上上篇文章写过你规划过自己的成长路线吗,自我认知和自我规划只是成长中的一个环节,私以为成长有三个环节:学习->管理自我->管理学习。

    蚂蚁安全柳星
  • 【2019领域驱动设计峰会】领域场景驱动设计实战工作坊

    领域场景驱动设计实战工作坊将以事件风暴为纵贯线,以领域场景为横切面,引入场景驱动设计与测试驱动开发完成从领域建模到编码实现的全过程实战。内容涵盖事件风暴、场景驱...

    ThoughtWorks
  • DDD中的建模方法有哪些[通俗易懂]

    在之前的文章中已经介绍了DDD相关的概念模式,DDD相关的业务技术架构,但是我们还没有找到一个核心的抓手去实践DDD。DDD的一个核心本质就是对业务建模,或者领...

    全栈程序员站长
  • 域名劫持事件频发 网站安全形势不容忽视

      6月26日消息,近日,安恒信息风暴中心在日常监测中发现了多起国内网站域名解析地址跳转至美国或加拿大等国外IP的情况。安恒信息风暴中心对此异常行为进行深入分析...

    安恒信息
  • 「领域驱动设计DDD」事件风暴简介:实现域驱动设计的简便方法

    事件风暴是一种快速,轻量级且未得到充分认可的群体建模技术,它对于加速开发团队而言非常强大,有趣且有用。作为Alberto Brandolini的心血结晶,它是G...

    首席架构师智库
  • 基于领域驱动设计的业务中台架构设计

    软件设计首要面对的挑战是如何应对复杂多变的业务问题。而对于业务中台来说,这个问题变得尤为突出。一方面,数字化时代,高度不确定并且快速变化的商业环境必然要求企业的...

    爱撸猫的杰
  • NASA和亚马逊正在合作开发可以预测太阳超级风暴的应用程序

    我们已经看到这些超级风暴过去曾造成破坏。1859年,据称发生了卡灵顿事件,这中断了电报通信。1989年冬天,加拿大魁北克省的数千名居民在水电中断时陷入了黑暗。这...

    AiTechYun
  • DDD实战课--学习笔记

    我认为,要想应用 DDD,首要任务就是要吃透 DDD 的核心设计思想,搞清楚 DDD、微服务和中台之间的关系。中台本质是业务模型,微服务是业务模型的系统落地,D...

    郑子铭
  • 限界上下文是什么鬼?DDD 最抽象的概念详解

    通用语言, 最主要的目的就是减少交流中信息丢失, 在实际开发中, 可能关联很多人, 例如有业务层面的业务细节制定者、领域专家、产品经理、项目经理 、架构师、开发...

    孙玄@奈学教育
  • DDD领域驱动实战(二) - 限界上下文(bounded context)

    限界上下文定义领域边界,以确保每个上下文含义在它特定的边界内都具有唯一的含义,领域模型则存在于这个边界之内。

    JavaEdge
  • 如何基于 DDD 构建微服务?

    本文将讨论微服务与 DDD 涉及到的概念、策划和设计方法,并且尝试将一个单体应用拆分成多个基于 DDD 的微服务。

    深度学习与Python

扫码关注腾讯云开发者

领取腾讯云代金券