DDD系列-限界上下文
2022-11-15 00:35:22    35    0    0
weibo-007

什么是限界上下文

这里要吐槽一下目前网站上的各种不说人话系列的文章,基本上全是书本上抄过来的,根本不是正常人能理解的,DDD难怪会变成玄学,读者在搜读文章的时候几乎是奔溃的状态。

为了好理解,也可能有局限性,但为了防止被喷,这里声明只是个人理解,不保证正确性。

假设我们面对一个庞大的系统,或者我们要从庞大的系统解放出来,我们首先想到的就是微服务,但是这里有一个难点,如何合理拆分微服务?我们就冲这个问题去解释。我们把限界上下文拆开看,限界表示划分,划分上下文,上下文表示名次。

1)我们拆分出来的一个个微服务就是一个个上下文

    a)支付微服务 = 支付上下文

    b)交易微服务 = 交易上下文

    c)风控微服务 = 风控上下文

2)上下文映射就是微服务直接调用方式,或者说调用协议

    a)假设你们部门很强势,那你的微服务永远不变,让别人适配你的协议,微信支付协议就长这样,你爱用不用

    b)假设你们部门很弱势,你要调用别人的微服务,那你加防腐层(适配器)去调用它的服务,你要去适配微信支付协议

3)关于微服务划分合理性,我们可以用事件风暴法来指导我们拆分合理性


所以当我们需要拆分一个庞大系统的时候,首先用事件风暴把微服务合理划分出来,然后确定微服务调用关系和协议。

事件风暴

事件风暴,首先得定义什么是事件,然后围绕事件进行头脑风暴。

什么是领域事件

领域事件是领域中发生的任何领域专家感兴趣的事情。这些事件我们从用户故事中就可以提取出来,比如我们用电影票务系统来举例,这里就会产生以下事件

1)当售票员标记座位后,产生一个座位已标记事件

2)当用户确认座位后,产生一个座位已确认事件

3)当售票员收到用户的确认之后,产生一个座位已预约事件

4)可能后续还有支付动作,会产生座位已支付事件

值得一提的是:领域事件不是技术概念,而是作为通用语言的一部分和领域专家,运营人员,产品团队达成一致。这一点很重要,很多技术团队内部有各种Event事件,然后这些Event事件和产品团队介绍的时候,需要加各种补充解释,其实完全没必要,领域事件在初期就需要和产品团队达成一致。

注意,领域事件的几点约束:

1)领域事件是表示已发生的动作,通常是名词+过去式动词,比如座位已标记,座位已预约

2)领域事件一定要和领域专家相关,不是一个技术概念

但是,基于用户故事的方式,可能不能完全覆盖领域事件,所以接下来介绍一种新的挖掘领域事件的方式:事件风暴

什么是事件风暴

事件风暴:一种协作式的对复杂业务领域进行探索的讨论形式,是一种灵活易调整的轻量级的适用于DDD的建模方法(暂时不能理解没关系)。可以通俗一点:用可视化的方式让架构师,产品,领域专家头脑里的东西达成一致

谁参与

架构师,产品经理,领域专家

什么时机

新产品初始时/老系统的重构前的梳理时

解决什么问题

扫盲并发现风险点,产品经理或者架构师并没有像领域专家一样专业的专业知识。这一点生活中也很常见,在专业的离婚协议制定中,律师这个领域专家会全程参与

准备工具

便利贴(多种颜色),白板,磁力贴,笔

实施步骤

笔者用的在线白板工具:https://www.xiaohuazhuo.com/

1)列出领域事件

事件表示已经发生的事实,可能需要保存下来,或者让别人响应。

所有决定关心的领域事件都可以列出来,命令方式为名词+过去式动词,使用橙色便利贴。

2)收集关注点和问题

热点表示关注点和问题,也可一是风险,代表这件事情值得特别关注,使用紫色标签。

比如下图的30分钟超时

3)标记命令和角色

蓝色表示决策命令,黄色表示角色,角色可以是人或者系统

决策命令:产生事件的动作,和事件一一对应

角色:决策命令一定是由某个人或者系统来完成的,可以具体化:比如售票员,定时系统

比如下图的用户和定时系统

4)外部系统

领域事件不一定由角色触发决策命令产生,也可以是外部系统,外部系统使用粉红色表示。

假设这个系统不做核销功能,整个核销功能引进外部的技术,那核销对这个系统而言就是外部系统

比如下图的核销系统

5)读模型

读模型是帮助角色在做出决策命令的时候,需要提前看到的信息,支撑角色做出决策命令,使用绿色表示

比如下图的商品信息

6)聚合

某个角色在某个聚合调用某种决策命令产生了某个事件,使用浅黄色表示

时间风暴是非常大的一张图,我们刚才讨论的是局部订单的情况,现在我们把进行缩放,把聚合找出来

为了方便看清,用辅助线标记了下,这里找出了三个聚合:用户,订单,评价

7)策略

最后,还有很多策略规则自动触发的一些动作,我们用深紫色表示

比如,评价中的黄反策略

事件风暴产物

实际上的事件风暴过程远远比上面的复杂,上面只是针对订单一个模块进行的。一张真实的事件风暴图可能入下图所示

发现界限上下文

基于事件风暴的大图,我们可以识别出里面的聚合,然后根据聚合划分界限上下文,其实就把我们微服务的边界划分出来了。

这里值得一提的是,可以视内部团队情况而定,不一定每个聚合都是一个微服务,比如团队不那么壮大的情况下,用户服务就可以包含会员,收件人等。

比如下面这种图,按照微服务划分就是3个微服务:用户微服务,订单微服务,评价微服务

之所以是这三个,是因为我们讨论的还不够深入,比如商品信息从哪儿来的,库存是如何设置的,只要讨论完了,会基于一张非常大的图进行微服务划分

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Pre: DDD系列-领域驱动设计思想概览

Next: DDD系列-领域划分

35
Sign in to leave a comment.
No Leanote account? Sign up now.
0 comments
Table of content