DDD—子域和限界上下文
一、域的概念和划分
DDD对业务领域划分到一定程度后,便将特定问题限定在了特定的边界内,这个特定的边界就是域,在边界内进行领域建模,微服务代码落地。
边界有大有小,领域可以进一步划分为子域,把问题聚焦到一个特定的业务范围内。
在领域不断细分的过程中,通常被分解为核心子域,通用子域和支撑子域
企业内决定核心竞争力的是核心子域里的业务,而没有个性化诉求,不在业务主流程上的为通用子域,另外一种不是企业核心竞争力能力的,但对于核心子域的建设是不可缺少的称为支撑子域,支撑子域和通用子域都可以被多个核心子域重复使用。
比如电商领域中,营销,推荐,购物,直播是他的核心子域,而这些核心业务逻辑都需要订单,支付,用户信息,所以这部分为通用子域,而支撑子域更多为公共服务的实现,如任何子域都需要使用到的数据字典,国际化,权限认证等。
![](https://img2020.cnblogs.com/blog/1135193/202105/1135193-20210528170445884-1751473504.png)
二、核心子域的选择
比如人作为一个领域的话,身高,体重,背景,外貌,性格,品行是子域,那么对于不同的人来说,核心子域是可以不同的,外貌协会会把外貌作为核心子域,拜金的会把背景作为核心子域。
在同一个领域,不同核心领域的选择,决定了一个企业的战略方向和商业模式,例如电商领域里,淘宝是C2C,京东是B2C,战略方向和商业模式最终会导致核心领域选择的不同,导致企业的核心投入占比不同。
所以核心子域的建模,要排在领域建模的首要位置,他会决定企业的投资方向和战略地位。
三、限界上下文(Bounded Context)
限界上下文定义了领域模型的边界和业务适用范围,使得团队所有成员明确什么内容应该在领域模型中实现,什么东西不应该出现
定义限界上下文通常考虑领域业务职责单一的因素,确定了职责边界后,将所有实现该领域职能相关的对象都放在同一个限界上下文边界内,而将所有与该职能无关的对象排除在上下文边界之外,限界上下文就是一个强制边界,保证领域职责的单一性。
部门的组织架构划分,实际就是定义部门的限界上下文,企业设置组织架构时,通常从部门职责出发,设立人力资源部,行政部,技术部,销售部,咨询部,部门的只能边界就是企业这个领域的上下文边界。在部门内聚集和部门相关技能的成员,职责。部门边界的区分是为了避免不相干的成员散落在各个部门,给人造成一种组织架构混乱的感觉,觉得这个企业的组织架构不够单一,界限明确,不能够专业的人干专业的事。
限界上下文本质上就是子域。当一个领域,我们划分的子域足够小的时候,就可以在子域内划分限界上下文,进行领域建模了,如果子域划分得足够小不可再拆分,那么限界上下文刚好和子域的边界一致,如果子域还能再次划分,一个子域内出现多个限界上下文,也是OK的
四、共同语言
三百六十行,行行出状元。在上文的部门职能上下文内,不同部门内的行话也是不一样的,比如技术部用技术相关的语言交流,人力资源部用人力相关的语言交流,这些共同语言组成了部门间的语言上下文边界
比如电商领域的淘宝,商品在进货阶段叫货物,销售阶段叫宝贝,快递阶段叫快递,一件东西在不同的阶段会有不同的表现形式,由于业务领域边界的不同,需要达成对领域内对象,实体的共同语言描述,避免造成歧义。
参考书籍 ——《基于DDD和微服务的中台架构与实现》欧创新、邓頔
参考书籍 ——《领域驱动设计》Eric Evans
参考书籍 ——《架构真经》Martin L. Abbott