其他分享
首页 > 其他分享> > DDD领域驱动设计落地实践(十分钟看完,半小时落地)

DDD领域驱动设计落地实践(十分钟看完,半小时落地)

作者:互联网

一、引子

不知今年吹了什么风,忽然DDD领域驱动设计进入大家视野。该思想源于2003年 Eric Evans编写的“Domain-Driven Design领域驱动设计”简称DDD,Evans DDD是一套综合软件系统分析和设计的面向对象建模方法。刚好公司领导强力推荐这个,抱着学习的心态,耗时5个月,体验了一把:“DDD从入门到弃坑”。

二、思想

学习网站:https://www.jdon.com/ddd.html

2.1 服务器后端发展三个阶段

DDD领域驱动设计落地实践(十分钟看完,半小时落地)

服务器后端发展三个阶段:

  1. 面向过程脚本:初始简单,业务复杂后,维护难度指数上升。-->基本不为主流使用
  2. 面向数据库表:初始难度中,业务复杂后,维护难度延迟后再指数上升。--->目前市面上主流
  3. 面向业务模型:DDD+SOA微服务的事件驱动的CQRS读写分离架构:应付复杂业务逻辑,以聚合模型替代数据表模型,以并发的事件驱动替代串联的消息驱动。真正实现以业务实体为核心的灵活拓展。初始难度高,业务复杂后,维护难度线性上升(也很不错)

2.2 DDD最大特点

DDD革命性在于:领域模型准确反映了业务语言,而传统微服务数据对象除了简单setter/getter方法外,没有任何业务方法,即失血模型,那么DDD领域模型就是充血模型(业务方法定义在实体对象中)

三、落地

3.1 领域模型设计

以渠道中心(一个微服务)作为例子来做领域模型设计,核心就是设计2个图,一个是战略设计图(宏观) ,一个是战术设计图(细节)。

1.领域战略设计图

战略设计图是从一个限界上下文的角度出发去分析业务场景。主要是宏观上的核心域、子域、实体关系图。demo如下图:

DDD领域驱动设计落地实践(十分钟看完,半小时落地)

2.领域战术设计图

战术设计图是从一个限界上下文的角度出发去分析业务场景。细化到核心业务字段、领域实体、值对象、领域服务、领域事件等等。基本上这个图画完,代码已经知道怎么写了。demo如下图:

DDD领域驱动设计落地实践(十分钟看完,半小时落地)

3.2 技术实现

整体项目框架分层图如下所示:

DDD领域驱动设计落地实践(十分钟看完,半小时落地)

如上图,4层典型DDD分层结构,

1.展现层:controller层。无业务逻辑

2.应用服务层:此层可以包含查询逻辑,但核心业务逻辑必须下沉到领域层。

3.领域服务层:业务在这里组装。仓储(资源库)接口在此层定义。

4.基础设施层:仓储(资源库)实现层+PO持久化层。

注:

1.简单查询不涉及业务,是可以直接从应用层直接穿透到PO查询,不需要经过domain层。如下图所示,DDD本身是不限制非业务类操作跨层调用的。

DDD领域驱动设计落地实践(十分钟看完,半小时落地)

2.DTO是不能存在于domain层的,DDD设计不认为DTO是业务对象,entity才是。或者传值简单数据类型也是可以的。

3.2.1 服务调用问题

1.域内调用

领域内调用,随便调用,丝般顺滑。至于实现,可以由一个核心域的仓储实现层(第四层)去实现多个Repository接口。(比如这里A是核心域的实体名,B是支撑域、通用域等)

DDD领域驱动设计落地实践(十分钟看完,半小时落地)

2.跨域调用

DDD领域驱动设计落地实践(十分钟看完,半小时落地)

跨域分为

3.2.2 包结构

包结构如下:

DDD领域驱动设计落地实践(十分钟看完,半小时落地)

展开包结构如下:

DDD领域驱动设计落地实践(十分钟看完,半小时落地)

展现层:Controller, 仅做接口的入口定义和编排转发,不做任何的业务处理;

应用服务层:application, 负责接口参数DTO的简单校验,以及DTO和实体值对象的数据转换,对于简单的业务,也可以在应用层加载实体直接执行实体行为方法;

领域层:

适配层: 在acl包下的feign定义依赖外部的接口,并在acl的adapter包编写转换,由仓储层操作实体时调用;

持久层: 与常用DAO定义一致,由仓储层操作实体时调用。

标签:调用,落地,模型,实体,业务,领域,十分钟,DDD
来源: https://blog.csdn.net/weixin_45439683/article/details/121108950