DDD系列-领域划分
2022-11-10 00:12:20    711    0    0
weibo-007

DDD系列-领域划分

什么是领域划分

领域划分是以分离关注点为原则对问题空间的划分。领域划分必然会划分成很多个子域。

子域是领域中某个方面的问题和解决它所涉及的一切

其实我们面对复杂问题的时候,都会采用这种方式,纵观我们整个社会,有各行各业,有餐饮业,保险业,房地产业,然后每个领域解决自己领域内的问题,最后连接成一个高效运作的社会形态。

同样,我们做互联网如果要达到高效运作的效果,就必须做到各司其职,做细做精。但是这里有一个难题,如果做领域划分,就跟社会上不会平白无故出现一个保险业一样,它肯定有社会普遍的问题,最终人们抽象成了一个保险业领域来解决保险相关的所有问题。

假设没有领域划分

其实很多业务初期的时候,都是没有领域划分的,基本是按照需求来。接下来我们看下,如果这样长期演变下去会有什么问题。笔者是做医疗的,还是用那个医疗的用户故事来讲解。

我们假设梳理出来了下面几个顶层用户故事

1)收集用户的病情

2)用户购买订单

3)指派订单给医生

4)医生接单

5)医生和患者IM对话

6)医生开具处方

7)用户购买处方药

假设在一个项目压力比较大,而研发leader又没有做太多思考的情况下,很容易将这6个顶层用户故事派发给6个研发同学,也就是按照需求来划分指责

这样会导致:

1)问题点和领域知识重叠,比如"用户提交订单"和"用户购买处方药"都会处理支付问题,支付领域的问题他们都需要处理一遍,痛苦加倍

2)基础模型重叠,比如"收集用户病情"和"医生接单"和"用户购买处方药"都会用到就诊人和病例的模型,他们很可能自己定义一套内部的模型,将来想打通简直就是噩梦

3)难以区分核心和非核心,如果你作为一个在线医疗系统,结果一半的人力在支付问题上,那可想而知,医疗真正的核心问题谁来解决?

领域划分解决的问题

很多人可能已经想到了,建立通用底层服务,然后上层业务统一调用底层服务,这样可能有一定的思路了,但是还不够彻底,因为一旦涉及到服务,就会涉及到拆分的依据和原则,这个问题就相当复杂了。所以我们假设带着这个思路去拆分一下上面的用户故事划分的域。

1)交易域,首先能想到的是交易域,这里处理支付相关的问题,所以支付领域的问题汇聚到这

2)订单域,这里包括订单,商品等重要的信息

2)对话域,作为医生和用户的医疗IM通用工具,这里需要处理各种个性化的通信协议,比如医嘱,病例等医疗特性内容

3)医生域,医生具备接单,看病,开处方等能力

所以还是上面的用户故事,但是人员的分配却千差万别

现在看看,如果我们充分做了领域划分(这里只是列举一个例子,可能医疗系统真实的领域划分不同),那可以解决我们按照需求来分配人员的缺点

1)问题点和领域知识聚焦,做支付那一波人每天都和支付问题打交道,做对话域那一波人每天都在和IM系统打交道

2)基础模型被拆分,订单和商品模型只在交易域里面

3)可以区分核心非核心,这里面医生域和交易域是核心,必须重点投入人力,前期我们可以投入更少的人力做功能有限的支付域和对话域

实际上,在DDD的思想中,根据重要性与功能将领域分为大致三类(视项目实际情况而定)的多个子域,分别是核心子域、支撑子域和通用子域。核心域是业务成功的主要促成因素,主要竞争力,支撑子域是支撑核心域的,而通用子域是业务系统的公用部分。

如何合理的进行领域划分

既然领域划分之后,人员可以高效的协作,但是,如果领域划分不合理,会导致开发人员的领域知识各种交叉,不排除逐步走向单体的可能,带来的灾难一样巨大的。所以合理的领域划分相当重要。这里有几种方法

1)参考行业,市面上比较成熟的领域,比如电商,金融,财务

      最快的方式是招一个领域架构师直接划分,架构师的能力相当强,直接通过直觉和经验进行划分

2)基于用户故事方法,既然用户故事是对问题的描述,领域划分是对问题的分界,所以可以从这个角度出发

     可以从整个产品涉及的角色,以及每个角色的用户故事描述出来,比如很容易区分运营域,用户域,他们做的事情完全不一样

下面介绍一种常用的模式,纵+横划分

基于用户故事的纵+横划分

因为领域的划分属于问题空间,所以当我们讨论领域划分的时候,只聚焦于问题。避免有任何技术相关的术语插入(比如模型,限界上下文)

首先需要把问题全部摆出来,然后有两个原则:

1)纵:根据业务目标和价值垂直划分

2)横:共性能力提取,划分通用域和支撑域

用户故事是非常复杂的,但是一定要列全,否则不可能再做横向划分,如果这一步划分的好,那产品架构和技术架构是比较接近的。

(注意:一下概念全部来自用户故事,因为在盘点的时候,每个业务都用到了这些概念,才会考虑下沉)


这里使用医疗领域典型的"医+药"模式来构建一个典型的领域划分,用户故事来自知乎的阿里健康的(实际的情况比这个更复杂)

https://zhuanlan.zhihu.com/p/125144917 

值得一提的是,这个图不是什么微服务架构图,这里没有任何技术的概念,仅仅是从用户故事出发得出来的领域划分。

下一个环节

我们上面的讨论都是在问题空间进行的,注意还没有到具体的解决方案空间,这时候才开始出现一些界限上下文的词语

 


 

 

Pre: DDD系列-限界上下文

Next: GO语言基础-数据竞争

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