如何使用事件风暴构建领域模型

微服务架构与开发 专栏收录该内容
28 篇文章 12 订阅

目录

一、事件风暴简述

二、事件风暴的准备工作

(一)事件风暴的参与者

(二)事件风暴要准备的材料

(三)事件风暴的场地

(四)事件风暴分析的关注点

三、利用事件风暴构建领域模型

(一)产品愿景

(二)业务场景分析

(三)领域建模

第一步:从命令和事件中提取产生这些行为的实体。

第二步:寻找聚合根及它关联的实体和值对象组合为聚合

第三步:划定限界上下文,根据上下文语义将聚合归类。

(四)微服务拆分与设计

四、事件风暴常见问题分析

(一)事件的粒度如何判定?

(二)对某个事件有歧义如何处理?

(三)领域模型周围的事件过多怎么办?

(四)成员完全不熟悉业务怎么办?

(五)没有领域专家怎么办?

参考书籍、文献和资料


一、事件风暴简述

事件风暴是一种快速探索复杂业务领域和对领域建模的实践。事件风暴从领域中关注的业务事件出发,在此过程中团队经过充分讨论,统一语言,最后找到领域模型。

事件风暴是一项团队活动,领域专家与项目团队通过头脑风暴的形式,罗列出领域中所有的领域事件,整合之后形成最终的领域事件集合,然后对每一个事件,标注出导致该事件的命令,再为每一个事件标注出命令发起方的角色。

命令可以是用户发起,也可以是第三方系统调用或者定时器触发等,最后对事件进行分类,整理出实体、聚合、聚合根以及限界上下文。

注意:能够引发事件的事情包括用户行为、外部系统所发生的事情以及时间的流逝。事件也有助于找到领域的边界,对属于的不同阐述可能就意味着存在边界。事件风暴中我们关注的东西:

  • 事件 -> 某个动作的结果
  • 属性 -> 事件的输入、输出
  • 命令 -> 某个动作
  • 实体 -> 命令的触发者

简单理解就是谁(实体)使用什么(输入)做了什么(命令、动作)产生了什么(输出)影响了什么(事件)。

二、事件风暴的准备工作

(一)事件风暴的参与者

  • 组织者:组织者应当熟悉事件风暴的整个流程,能够组织大家顺利完成事件风暴;
  • 领域专家:领域专家应该是精通业务的人,在事件风暴过程中,要负责澄清一些业务上的概念,思考业务上有没有遗漏的事件;
  • 项目成员:负责开发这个项目的成员,所有角色都可参加,比如BA、QA、UX、DEV。因为事件风暴可以快速让整个团队了解整个项目的业务流程。

领域专家是事件风暴中必不可少的核心参与者。领域专家就是对业务或问题域有深刻见解的主题专家,他们非常了解业务和系统是怎么做的,同时也深刻理解为什么要这样设计。如果你的公司里并没有这个角色,那也没关系,你可以从业务人员、需求分析人员、产品经理或者在这个领域有多年经验的开发人员里,按照这个标准去选择合适的人选。

除了领域专家,事件风暴的其他参与者可以是 DDD 专家、架构师、产品经理、项目经理、开发人员和测试人员等项目团队成员

(二)事件风暴要准备的材料

事件风暴参与者会将自己的想法和意见写在即时贴上,并将贴纸贴在墙上的合适位置,我们戏称这个过程是“刷墙”。所以即时贴和水笔是必备材料,另外,你还可以准备一些胶带或者磁扣,以便贴纸随时能更换位置。

在这个过程中,我们要用不同颜色的贴纸区分领域行为。如下图,我们可以用蓝色表示命令,用绿色表示实体,橙色表示领域事件,黄色表示补充信息等。补充信息主要用来说明注意事项,比如外部依赖等。颜色并不固定,这只是我的习惯,团队内统一才是重点。

(三)事件风暴的场地

只需要一堵足够长的墙和足够大的空间就可以了。墙是用来贴纸的,大空间可以让人四处走动,方便合作。撤掉会议桌和椅子的事件风暴,你会发现参与者们的效率更高。

事件风暴的发明者曾经建议要准备八米长的墙,这样设计就不会受到空间的限制了。当然,这个不是必要条件,看各自的现实条件吧,不要让思维受限就好。

(四)事件风暴分析的关注点

在领域建模的过程中,我们需要重点关注这类业务的语言和行为

比如某些业务动作或行为(事件)是否会触发下一个业务动作,这个动作(事件)的输入和输出是什么?是谁(实体)发出的什么动作(命令),触发了这个动作(事件)…我们可以从这些暗藏的词汇中,分析出领域模型中的事件、命令和实体等领域对象。

三、利用事件风暴构建领域模型

领域建模的过程主要包括产品愿景、业务场景分析、领域建模和微服务拆分与设计这几个重要阶段。

相关案例具体见:https://blog.csdn.net/xiaofeng10330111/article/details/105148032

相关更详细的细节见欧创新极客时间课程《DDD实战》,这里只是学习总结。

(一)产品愿景

产品愿景的主要目的是对产品顶层价值的设计,使产品目标用户、核心价值、差异化竞争点等信息达成一致,避免产品偏离方向。

产品愿景的参与角色:领域专家、业务需求方、产品经理、项目经理和开发经理。

在建模之前,项目团队要思考这样两点:

  • 用户中台到底能够做什么?
  • 它的业务范围、目标用户、核心价值和愿景,与其它同类产品的差异和优势在哪里?

这个过程也是明确用户中台建设方向和统一团队思想的过程。参与者要对每一个点(下图最左侧列的内容)发表意见,用水笔写在贴纸上,贴在黄色贴纸的位置。这个过程会让参与者充分发表意见,最后会将发散的意见统一为通用语言,建立如下图的产品愿景墙。如果你的团队的产品愿景和目标已经很清晰了,那这个步骤你可以忽略。

(二)业务场景分析

场景分析是从用户视角出发的,根据业务流程或用户旅程,采用用例和场景分析,探索领域中的典型场景,找出领域事件、实体和命令等领域对象,支撑领域建模。事件风暴参与者要尽可能地遍历所有业务细节,充分发表意见,不要遗漏业务要点。

场景分析的参与角色:领域专家、产品经理、需求分析人员、架构师、项目经理、开发经理和测试经理。

用户中台有这样三个典型的业务场景:

  • 第一个是系统和岗位设置,设置系统中岗位的菜单权限;
  • 第二个是用户权限配置,为用户建立账户和密码,设置用户岗位;
  • 第三个是用户登录系统和权限校验,生成用户登录和操作日志。

我们可以按照业务流程,一步一步搜寻用户业务流程中的关键领域事件,比如岗位已创建,用户已创建等事件。

再找出什么行为会引起这些领域事件,这些行为可能是一个或若干个命令组合在一起产生的,比如创建用户时,第一个命令是从公司 HR 系统中获取用户信息,第二个命令是根据 HR 的员工信息在用户中台创建用户,创建完用户后就会产生用户已创建的领域事件。

当然这个领域事件可能会触发下一步的操作,比如发布到邮件系统通知用户已创建,但也可能到此就结束了,你需要根据具体情况来分析是否还有下一步的操作。

场景分析时会产生很多的命令和领域事件。用蓝色来表示命令,用橙色表示领域事件,用黄色表示补充信息,比如用户信息数据来源于 HR 系统的说明。

(三)领域建模

领域建模时,我们会根据场景分析过程中产生的领域对象,比如命令、事件等之间关系,找出产生命令的实体,分析实体之间的依赖关系组成聚合,为聚合划定限界上下文,建立领域模型以及模型之间的依赖。领域模型利用限界上下文向上可以指导微服务设计,通过聚合向下可以指导聚合根、实体和值对象的设计。

领域建模的参与角色:领域专家、产品经理、需求分析人员、架构师、项目经理、开发经理和测试经理。

具体可以分为这样三步:

第一步:从命令和事件中提取产生这些行为的实体。

用绿色贴纸表示实体。通过分析用户中台的命令和事件等行为数据,提取了产生这些行为的用户、账户、认证票据、系统、菜单、岗位和用户日志七个实体。

第二步:寻找聚合根及它关联的实体和值对象组合为聚合

根据聚合根的管理性质从七个实体中找出聚合根,比如,用户管理用户相关实体以及值对象,系统可以管理与系统相关的菜单等实体等,可以找出用户和系统等聚合根。然后根据业务依赖和业务内聚原则,将聚合根以及它关联的实体和值对象组合为聚合,比如系统和菜单实体可以组合为“系统功能”聚合。

按照上述方法,用户中台就有了系统功能、岗位、用户信息、用户日志、账户和认证票据六个聚合。

第三步:划定限界上下文,根据上下文语义将聚合归类。

根据用户域的上下文语境,用户基本信息和用户日志信息这两个聚合共同构成用户信息域,分别管理用户基本信息、用户登录和操作日志。认证票据和账户这两个聚合共同构成认证域,分别实现不同方式的登录和认证。

系统功能和岗位这两个聚合共同构成权限域,分别实现系统和菜单管理以及系统的岗位配置。根据业务边界,我们可以将用户中台划分为三个限界上下文:用户信息、认证和权限。

(四)微服务拆分与设计

原则上一个领域模型就可以设计为一个微服务,但由于领域建模时只考虑了业务因素,没有考虑微服务落地时的技术、团队以及运行环境等非业务因素,因此在微服务拆分与设计时,我们不能简单地将领域模型作为拆分微服务的唯一标准,它只能作为微服务拆分的一个重要依据。

微服务的设计还需要考虑服务的粒度、分层、边界划分、依赖关系和集成关系。除了考虑业务职责单一外,我们还需要考虑将敏态与稳态业务的分离、非功能性需求(如弹性伸缩要求、安全性等要求)、团队组织和沟通效率、软件包大小以及技术异构等非业务因素。

微服务设计建议参与的角色:领域专家、产品经理、需求分析人员、架构师、项目经理、开发经理和测试经理。

用户中台微服务设计如果不考虑非业务因素,我们完全可以按照领域模型与微服务一对一的关系来设计,将用户中台设计为:用户、认证和权限三个微服务。

但如果用户日志数据量巨大,大到需要采用大数据技术来实现,这时用户信息聚合与用户日志聚合就会有技术异构。虽然在领域建模时,我们将他们放在一个了领域模型内,但如果考虑技术异构,这两个聚合就不适合放到同一个微服务里了。我们可以以聚合作为拆分单位,将用户基本信息管理和用户日志管理拆分为两个技术异构的微服务,分别用不同的技术来实现它们。

四、事件风暴常见问题分析

(一)事件的粒度如何判定?

事件是领域专家关心的业务事件。所以它不能比领域专家关心的业务更细,因为那将毫无意义。

举个例子,如果我们关心的是一个人一天的作息,那我们可能关心的是用户已起床,用户已吃早餐,用户已上班。但我们不会关心到更细节,比如:用户已睁眼,用户已洗漱,用户已出门,用户已上地铁……

同时,事件粒度也不能太粗,因为太粗粒度的事件不利于寻找领域模型。比如我们在平台上发一篇文章的业务。如果你只写一个“文章已发布”,那就可能会丢失掉一些比较重要的业务流程。尝试改成:文章已保存,文章已申请审核,文章已通过审核,文章已审核失败,文章已对外发表,文章已加入分类,文章已推荐……你会发现,中间多了一个审核的过程,如果不找到这些命令,就很有可能遗漏掉“文章审核单”之类的模型。

(二)对某个事件有歧义如何处理?

在实施事件风暴的时候,不必刚开始就花太多的时间在上面,阻塞了后面的事件发掘。

用一个醒目的标记记下来,后面再回过头来充分讨论。

或许最开始有歧义的地方,在事件逐渐完善,领域模型定义出来后,就没有歧义了。

(三)领域模型周围的事件过多怎么办?

警惕:一个领域模型不应该包含过多的领域事件,因为这会让这个模型变得很大,很复杂。你们需要考虑把这个领域模型拆分开了。

仔细思考一下,这个领域模型是不是可以拆成两个?一些下面的实体是不是可以拿出来单独作为一个聚合根?它们中的一些事件表述是不是有歧义?可不可以拆开来划分到两个限界上下文中?这种情况,是应该把它们拆开的。

比如“用户”在权限上下文中我们关注的是它的角色和权限,它是否登录成功,它的密码等等。

而在商品上下文中,我们关注的是它的姓名,电话,地址等等。

(四)成员完全不熟悉业务怎么办?

可以由领域专家先进行业务大概流程的讲解。如果有UX已经设计好的图就更好了。大家可以在这个环节发出自己的疑问,澄清一些关键信息。

领域专家也可以把主要的业务流程写下来,打印到纸上或者反映到大屏幕上。

(五)没有领域专家怎么办?

如果你的公司里并没有这个角色,那也没关系,你可以从业务人员、需求分析人员、产品经理或者在这个领域有多年经验的开发人员里,按照这个标准去选择合适的人选。总之,团队总得是有人了解业务的,比如BA(有些团队可能是PM、TL等)。如果实在没有,可以让领域专家写一份上面那种主要的业务流程,大家按照这个业务流程来做。

但还是最好有一个领域专家,因为出现分歧的时候是很需要沟通达成一致的。如果没有领域专家在,团队有可能得到一些不准确的模型和语言。

除此之外,团队成员也可以查阅相关的文献资料去了解业务。比如金融系统、医疗系统等等都是有现成的行业案例可以研究的。

 

参考书籍、文献和资料

1.极客时间课程《DDD实战》,欧创新,2019.

2.郑天民. 微服务设计原理与架构. 北京:人民邮电出版社,2018.

3.徐进,叶志远,钟尊发,蔡波斯等. 重新定义Spring Cloud. 北京:机械工业出版社. 2018.

4.https://www.cnblogs.com/avalon-merlin/p/11397077.html

5.https://blog.csdn.net/yasinshaw/article/details/103307125

  • 6
    点赞
  • 0
    评论
  • 16
    收藏
  • 一键三连
    一键三连
  • 扫一扫,分享海报

相关推荐
©️2020 CSDN 皮肤主题: 创作都市 设计师:CSDN官方博客 返回首页
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值