什么是DDD领域驱动设计

一、DDD背景

2003 年埃里克·埃文斯(Eric Evans)发表了《领域驱动设计》(Domain-Driven Design –Tackling Complexity in the Heart of Software)这本书,从此领域驱动设计(Domain Driven Design,简称 DDD)诞生。DDD 核心思想是通过领域驱动设计方法定义领域模型,从而确定业务和应用边界,保证业务模型与代码模型的一致性。

但 DDD 提出后在软件开发领域一直都是“雷声大,雨点小”!直到 Martin Fowler 提出微服务架构,DDD 才真正迎来了自己的时代。

大部分的Java程序员开发生涯是从学习J2EE经典的分层理论开始的(Action、Service、Dao),在这种分层理论中,我们基本没有啥机会使用那些所谓的“行为型”的设计模式,这里的核心原因,就是J2EE经典分层的开发方式是“贫血模型”。

二、什么是DDD

如下图,传统的敏捷开发模式,我们更多的使用数据驱动设计的思想,按照功能模块来,拆分成一个个的小模块,每个模块要实现什么功能,需要什么样的数据,然后就通过ER数据建模,建库建表后开干了,这样会导致N个系统中重复的功能会反复建设,Service层编写了繁杂的业务逻辑,耦合度极高,经常牵一发而动全身。
 在这里插入图片描述
什么是DDD领域驱动设计_第1张图片

而DDD是指需求输入的时候,从领域开始聊起,比如教育是一个领域,先从校长聊起,然后聊到他的关联实体老师,学生,考试等等,这些实体之间的关联关系是什么,他们各自都会有哪些行为方法和业务逻辑。聊清楚后进行实体的建模,聚合实体的行为形成一个个领域服务,比如学生+老师的实体组合成了上课这一领域服务,之后再对领域服务进行编排,组成核心的可复用的业务逻辑。
 再之后就是经过领域模型划分微服务界限,映射模型和微服务代码后进行开发,DDD就是以领域为入口,来解决产品设计,研发的思想。

在这里插入图片描述

DDD通过领域建模,编排核心业务逻辑后映射到微服务开发的过程,有利于构建出企业可复用的核心能力,减少重复的IT建设,同时开发者可以根据模型和微服务代码设计的对应关系,快速清晰的完成开发。同时后面博文会讲到DDD严格的分层结构设计,能够帮助构建一个“低耦合,高内聚”,可演进的系统。

三、DDD的战略和战术

DDD不是架构,而是架构设计思想,演进的方法论,旨在聚焦业务领域模型来控制业务的复杂性,同时分离技术和业务耦合的复杂性。
  DDD包括战略设计和战术设计两部分
  战略设计:从业务视角出发,业务领域专家和技术专家通过事件风暴,建立共同的语言,构建领域模型,同时划分好领域的限界上下文,并以限界上下文作为微服务拆分和设计的边界,做业务核心逻辑的编排,从而在业务中台构建可复用的核心能力。
  战术设计:从技术角度出发,聚焦于领域模型如何映射到微服务代码开发的实现上。限界上下文和领域模型作为输入,从领域模型中抽象出来聚合,聚合根,实体,值对象,领域服务,领域事件,应用服务编排,仓储等,以表格或其他形式一一对照模型去设计代码,并最终结合分布式缓存,消息最终一致性等基础支撑实现落地。
  DDD按照一定规则将业务领域细分,细分到一定程度后,DDD将要解决的问题限定在特定范围内,这个过程中,可以将领域划分为子域,子域还可以继续划分为子子域,直到细分的程度,可以明确的区分不同业务领域,又不至于过度拆分,并适合微服务团队实施落地。DDD通常将划分后的子域区分为核心子域,支撑子域和通用子域。比如电商领域的子域划分
   
什么是DDD领域驱动设计_第2张图片

DDD这种子域的划分方法,可以帮助企业IT建设过程中确定中台的领域边界。

四、DDD、中台和微服务如何协同工作

业务中台的形成,实际也是业务领域不断细分,演进和能力沉淀的过程,所以中台是DDD战略设计的落地,DDD最擅长的就是领域建模。
  微服务的架构设计,参照着建模后的领域模型和限界上下文,作为微服务拆分的边界和依据,然后微服务与领域里的一个个子域互相映射,完成代码开发,是DDD的战术落地。
  
什么是DDD领域驱动设计_第3张图片

本文先从粗粒度来描述DDD战略设计和战术设计的实现,细粒度的实现待后面更新完子域,限界上下文,实体和值对象,聚合和聚合根,仓储模式,领域事件,分层架构等等后自然了解。下面看领域建模和中台建设,如何映射与关联。

什么是DDD领域驱动设计_第4张图片

通用中台对应的DDD的通用子域和支撑子域,实现企业可复用的通用业务能力,核心中台对应DDD的核心子域,这部分是DDD战略设计落地的产物。
领域模型和限界上下文,则与中台建设中的微服务对应,DDD建立的领域模型可以作为微服务划分的依据,完成微服务的拆分和开发,这部分是DDD战术设计落地的产物。
中台业务抽象就是领域建模的过程,系统抽象就是微服务设计过程,中台业务建模和落地,大致分如下几步
1、选取主领域模型,按照业务流程节点,将业务划分为业务中台(多个核心子域),将通用的功能和支撑划分为通用中台(通用域,支撑域),较大范围的业务领域,需要再逐级划分为大小合适的领域再构建领域模型
2、选取逻辑相对完整的领域模型作为主领域模型(如用户这个领域对象,常常分散到不同的领域模型中)以主领域为基准,扫描其他中台领域模型,检查是否存在功能重叠的模型,合并到主领域模型,完成领域模型的提炼
3、选择其他主领域模型重复第二步,直到完成所有领域模型的比对
4、将领域模型作为微服务设计的输入,完成微服务拆分和设计

什么是DDD领域驱动设计_第5张图片

你可能感兴趣的:(架构设计,系统架构,架构,DDD)