您当前的位置:首页 > 电脑百科 > 程序开发 > 架构

架构师必备 - DDD之落地实践

时间:2022-08-29 13:46:03  来源:今日头条  作者:互联网架构小马哥

今天带大家认识下DDD,一个听起来很垃圾却真的很牛X的设计思想,架构师必备!

前言

在日常工作中,接手或维护的工程,大多数使用的是三层架构,即controller、service、dao三层,在使用的过程中,会遇到很多问题:

  • 面向数据建模,面向过程编程,没有真正“面向对象”
  • 只注重结果,不注重过程,service层动辄数百上千行,充斥着过程代码、胶水代码,要么臃肿、要么流水账、要不重复、要么逻辑分散,后期极难维护
  • 代码耦合严重,层与层之间互相调用、逆向调用,牵一发而动全身
  • 代码无法体现业务,在大家都不爱写注释的情况下,随着时间的推移,代码业务逻辑将无人理解,不敢改也改不动。

那么有没有一个好的解决方案呢?今天要讲的DDD就是一个不错的选择。

DDD

DDD,即领域驱动设计,完美的解决了以上问题:

  • 面向领域建模,面向对象编程,代码直接映射现实世界概念,贴近业务,离客户更近
  • 领域逻辑高内聚,符合JAVA开发原则
  • 技术细节变更如数据库、缓存、定时器等的变更对业务逻辑影响比较小,非常适合插件式架构
  • 代码可读性、可维护性更强,对后续扩展、移植等支持更好,分层更加科学

DDD的概念,在网上很容易找到,这里就不赘述了。

然而网上DDD的文章虽然很多,但大多数是理论知识,介绍的无非就是一些名词:战略设计、战术设计、核心域、支撑域、值对象、实体、聚合... 对我们实际落地却没有太多的帮助,下面介绍下我在SpringBoot中应用DDD的落地方案。

落地方案

1、代码分层

 

代码分层

  • 用户接口层:图中的api包(即controller层,我嫌controller后缀太长...)
  • 应用层:这里使用了命令模式,并且读写分离成了两个包(command、query),如果不使用命令模式可以合并成一个service包
  • 领域层:domain包,使用JPA(对DDD有良好的支持)
  • 基础设施层:infra包,其他所有的公用组件都放在这里,如果使用DIP依赖倒置,那么实现类也放在这里。
  • model模型:model包,用于存放不同层间传递的对象,这些对象我试过放到好些地方,最后发现还是提出来统一放在一个包下比较好(便于服务间调用时共用对象)

2、层级关系及模型传递

 

分层及调用关系

3、分层详细说明

  • api包(controller)
@Tag(name = "用户", description = "用户")
@RestController
@RequestMApping(value = "/api/sys-user")
public class SysUserApi extends BaseApi {


    @ApiResult
    @Operation(summary = "根据ID查询用户")
    @GetMapping("/{id}")
    public SysUserVo get(@PathVariable Long id) {
        return queryExecutor.execute(new SysUserByIdQry(id));
    }


    @Pagination(total = true)
    @ApiResult
    @Operation(summary = "分页查询用户")
    @GetMapping
    public List<SysUserVo> getList(SysUserQo sysUserQo) {
        return queryExecutor.execute(new SysUserListQry(sysUserQo));
    }


    @ApiResult
    @Operation(summary = "新增用户")
    @PostMapping
    public void save(@Valid @RequestBody SysUserDto sysUserDto) {
        commandExecutor.execute(new SysUserCommonCmd(sysUserDto));
    }
}

在BaseApi中封装了两个命令执行类queryExecutor和commandExecutor,调用应用层时执行不同的命令即可,无需@Autowired引入不同的服务

@ApiResult加上这个自定义注解后,对返回结果统一封装

@Pagination加上这个自定义注解后,会自动将分页参数存入线程变量,后面查询时也会自动获取分页参数,返回结果统一封装时也会加上分页信息

Qo是查询参数对象,Dto是增删改等命令参数对象,返回对象为Vo,这里要注意,Entity绝对不能暴露到这一层,需要转换为Vo再返回

在这一层中,每个方法几乎就是一行执行命令的语句,一般情况不进行业务逻辑(当然也有特殊情况咯)

  • command包
@AllArgsConstructor
public class SysDeptAddCmd implements Command<Void> {


    private SysDeptDto sysDeptDto;


    @Override
    public Void execute(Executor executor) {
        // 获取命令的接收者:领域服务
        SysDeptManager receiver = executor.getReceiver(SysDeptManager.class);
        // 对象模型转换,由DTO转为Entity,使用了MapStruct
        SysDept sysDept = SysDeptMapper.INSTANCE.toSysDept(sysDeptDto);
        // 使用JPA保存
        receiver.save(sysDept);
        return null;
    }
}

增删改命令,很薄的一层,作为一项工作的组织者,几乎没有业务逻辑,调用领域服务和充血对象方法

命令模式,实现自定义Command接口,泛型为返回值

通过属性和构造方法(使用lombok注解)接收参数

一个命令里只有一个execute方法,缺点是会产生大量的命令类,一个类相当于之前service类中的一个方法,但是这样符合了单一职责原则

通过executor.getRecerver方法获取到领域服务(manager)

DTO绝对不下探到领域层中,需要先由DTO转换为Entity(转换方法这里使用的MapStruct,以后再单独细讲)

  • query包
@AllArgsConstructor
public class SysDeptByIdQry extends CommonQry<SysDeptVo> {


    private Long id;


    @Override
    public SysDeptVo execute(Executor executor) {
        if (id == null) {
            throw new BusinessException("部门ID不能为空");
        }
        QSysDept sysDept = QSysDept.sysDept;
        return queryFactory.select(this.fields())
                .from(sysDept)
                .where(sysDept.deleted.eq(false), sysDept.id.eq(id))
                .fetchOne();
    }


    /**
     * 部门VO映射
     *
     * @return QBean<SysDeptVo>
     */
    public static QBean<SysDeptVo> fields() {
        QSysDept sysDept = QSysDept.sysDept;
        return Projections.fields(
            SysDeptVo.class,
            sysDept.deptName,
            sysDept.orderNum,
            sysDept.id
        );
    }
}

命令模式,继承自定义CommonQry基类(此类也实现了自定义的Command接口,其中引用了QueryDSL的queryFactory类,且封装了分页方法),泛型为返回值

query包中的查询命令与command包中的命令大体相同,唯一区别是query命令理论上直接查询数据库,不调用领域层

由于JPA对于复杂查询不太好用,这里强烈推荐使用QueryDSL(以后再单独细讲),图中是一个简单的使用例子

  • domain包

类较多,代码部分不一一罗列:

由Entity类自动生成数据库表,仅维护Entity类(屏蔽数据库)

设计Entity时根据实际业务灵活使用@.NEToMany、@OneToOne等注解(聚合根的概念)

聚合根不要太大,80%的情况一个聚合根中只包含一个实体(不要过度设计成大聚合根)

不要使用贫血模型,而是要面向对象,属于对象的方法要放到对象中,但是对象中不建议引入仓库repository类,需要操作数据库的方法写在领域服务manager里

业务逻辑尽量写在领域服务(manager)中,不断提取、抽象不同的方法供应用层调用

适当的使用领域事件,JPA可以在Entity中使用@DomainEvents注解来发送领域事件

心得

  • 通过DDD对业务理解更加透彻,写的代码可以更好的传达客户的业务诉求
  • 能够尽情地编写低耦合的、符合单一职责、开闭等原则、封装、继承、多态的代码,是很身心愉悦的
  • 前期相比传统架构代码量更多,开发人员前期投入更多:
  • 领域的合理划分、实体的合理设计
  • 大量的DTO、VO等数据对象
  • 大量的数据对象转换方法
  • 大量的命令类
  • ...

但是,除非是特别简单的功能,对于一个中等复杂的系统,这些前期的付出还是值得的,一张图说明:

 

小结

以上简单介绍了下我对DDD的理解和实践,并通过实际的代码展现了如何在SpringBoot中应用DDD,希望能为大家提供一个思路。

原文链接:
https://mp.weixin.qq.com/s/n2p9UmHBcuCwrWnLHgLktw



Tags:架构   点击:( )  评论:( )
声明:本站部分内容及图片来自互联网,转载是出于传递更多信息之目的,内容观点仅代表作者本人,如有任何标注错误或版权侵犯请与我们联系(Email:[email protected]),我们将及时更正、删除,谢谢。
▌相关推荐
今天带大家认识下DDD,一个听起来很垃圾却真的很牛X的设计思想,架构师必备!前言在日常工作中,接手或维护的工程,大多数使用的是三层架构,即controller、service、dao三层,在使用的过...【详细内容】
2022-08-29  Tags: 架构  点击:(3)  评论:(0)  加入收藏
架构师可以说是许多IT程序员的终极职业目标,这一岗位在技术团队中的发挥着总指挥和总架构的重要作用。因此,能力越大责任越大。一名合格的架构师需要具备多项基本能力。本文为...【详细内容】
2022-08-24  Tags: 架构  点击:(5)  评论:(0)  加入收藏
通过本文可快速了解:1.为何使用 MVI2.为何最终考虑 SharedFlow 实现3.repeatOnLifecycle + SharedFlow 实现 MVI 思路为何使用 MVIMVI 是一响应式模型,通过唯一入口入参,并从唯...【详细内容】
2022-08-23  Tags: 架构  点击:(12)  评论:(0)  加入收藏
微服务能够对企业产生积极影响。因此,了解如何处理微服务架构(MSA)以及一些微服务设计模式,一个微服务架构的一些通用目标或者设计原则是很有价值的。下面是在微服务架构方案中...【详细内容】
2022-08-16  Tags: 架构  点击:(17)  评论:(0)  加入收藏
编辑:陈萍、杜伟研究者希望这篇文章对神经网络架构感兴趣的人有所帮助,特别是那些正在寻找不同角度进行研究的研究者。深度学习的基本原理可以追溯到几十年前,20 世纪 80 年代...【详细内容】
2022-08-15  Tags: 架构  点击:(11)  评论:(0)  加入收藏
项目架构图如下: 项目结构图的说明:客户端可以是pc端,也可以是手机,或者其它的移动设备,当客户端向后台发送请求的时候,首先需要经过我们的路由器,路由器根据我们的VIP(虚拟IP地...【详细内容】
2022-08-11  Tags: 架构  点击:(28)  评论:(0)  加入收藏
六边形架构是一种用于设计软件应用程序的架构模式。近年来,它的受欢迎程度有所增加,因为它是传统分层架构的替代品。 分层架构有什么问题?这种架构模式应用 SoC(关注点分离)原则...【详细内容】
2022-08-10  Tags: 架构  点击:(17)  评论:(0)  加入收藏
曾经因为一个糟糕的API而感到沮丧吗?在这个微服务的世界里,后端API的一致性设计是必不可少的。今天,我们将讨论一些可遵循的最佳实践。我们将保持简短和甜蜜&mdash;&mdash;所以...【详细内容】
2022-08-10  Tags: 架构  点击:(0)  评论:(0)  加入收藏
作者:张哲来源:华章科技 01 推荐系统技术架构下面来看下短视频社区平台的推荐系统架构是如何划分的,由底层往上分别是日志信息层、模型策略层、数据计算层、数据结果层与用户交...【详细内容】
2022-08-07  Tags: 架构  点击:(28)  评论:(0)  加入收藏
Android系统的层次架构非常清晰,其平台由应用程序、应用程序框架、系统库、Android运行时以及Linux内核5部分组成。 APPLICATIONS(应用程序)Android平台默认包含了主要的应用...【详细内容】
2022-08-07  Tags: 架构  点击:(22)  评论:(0)  加入收藏
▌澳门威斯尼斯人app官方下载推荐
今天带大家认识下DDD,一个听起来很垃圾却真的很牛X的设计思想,架构师必备!前言在日常工作中,接手或维护的工程,大多数使用的是三层架构,即controller、service、dao三层,在使用的过...【详细内容】
2022-08-29  互联网架构小马哥  今日头条  Tags:架构   点击:(3)  评论:(0)  加入收藏
可观察性是一把覆盖多个移动部件的宽伞。服务网格覆盖了很多领域,无需我们编写一行代码。服务网格和可观察性是微服务社区中的热门话题。在本趋势报告中,我们将详细探讨服务网...【详细内容】
2022-08-26   qaseven  网易  Tags:微服务   点击:(8)  评论:(0)  加入收藏
本期作者周佳辉哔哩哔哩资深开发工程师2017 年加入 B 站,先后从事账号、网关、基础库等开发工作。编码 C/V 技能传授者,技术文档背诵者。开源社区爱好者,安全技术爱好者,云计算...【详细内容】
2022-08-25  高可用架构    Tags:API 网关   点击:(5)  评论:(0)  加入收藏
微服务能够对企业产生积极影响。因此,了解如何处理微服务架构(MSA)以及一些微服务设计模式,一个微服务架构的一些通用目标或者设计原则是很有价值的。下面是在微服务架构方案中...【详细内容】
2022-08-16  Coolman945    Tags:架构   点击:(17)  评论:(0)  加入收藏
CQRS 是一种 微服务 架构模式 ,它代表命令和查询责任分离。这种模式背后的基本思想是将写操作与读操作分开。不是使用一个数据存储来执行 CRUD 操作,而是在一个数据存储上执行...【详细内容】
2022-08-14  小柴学Java    Tags:CQRS   点击:(16)  评论:(0)  加入收藏
项目架构图如下: 项目结构图的说明:客户端可以是pc端,也可以是手机,或者其它的移动设备,当客户端向后台发送请求的时候,首先需要经过我们的路由器,路由器根据我们的VIP(虚拟IP地...【详细内容】
2022-08-11  再多一点呢    Tags:架构   点击:(28)  评论:(0)  加入收藏
六边形架构是一种用于设计软件应用程序的架构模式。近年来,它的受欢迎程度有所增加,因为它是传统分层架构的替代品。 分层架构有什么问题?这种架构模式应用 SoC(关注点分离)原则...【详细内容】
2022-08-10  解道Jdon    Tags:SpringBoot   点击:(17)  评论:(0)  加入收藏
曾经因为一个糟糕的API而感到沮丧吗?在这个微服务的世界里,后端API的一致性设计是必不可少的。今天,我们将讨论一些可遵循的最佳实践。我们将保持简短和甜蜜&mdash;&mdash;所以...【详细内容】
2022-08-10  IT架构师联盟   网易号  Tags:架构   点击:(0)  评论:(0)  加入收藏
作者:张哲来源:华章科技 01 推荐系统技术架构下面来看下短视频社区平台的推荐系统架构是如何划分的,由底层往上分别是日志信息层、模型策略层、数据计算层、数据结果层与用户交...【详细内容】
2022-08-07  华章科技  今日头条  Tags:架构   点击:(28)  评论:(0)  加入收藏
目前,业界最常见的软件范例有:单体(Monolith)和微服务架构两种类型。两者的逻辑结构如下图所示。...【详细内容】
2022-08-05  51CTO  搜狐号  Tags:微服务   点击:(32)  评论:(0)  加入收藏
站内最新
站内热门
站内头条