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

简介: 今天带大家认识下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时根据实际业务灵活使用@OneToMany、@OneToOne等注解(聚合根的概念)

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

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

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

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

心得

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

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


小结

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

目录
打赏
0
0
0
0
63
分享
相关文章
极氪汽车云原生架构落地实践
随着极氪数字业务的飞速发展,背后的 IT 技术也在不断更新迭代。极氪极为重视客户对服务的体验,并将系统稳定性、业务功能的迭代效率、问题的快速定位和解决视为构建核心竞争力的基石。
Linux多节点多硬盘部署MinIO:分布式MinIO集群部署指南搭建高可用架构实践
通过以上步骤,已成功基于已有的 MinIO 服务,扩展为一个 MinIO 集群。该集群具有高可用性和容错性,适合生产环境使用。如果有任何问题,请检查日志或参考MinIO 官方文档。作者联系方式vx:2743642415。
495 57
一文带你从入门到实战全面掌握RocketMQ核心概念、架构部署、实践应用和高级特性
本文详细介绍了分布式消息中间件RocketMQ的核心概念、部署方式及使用方法。RocketMQ由阿里研发并开源,具有高性能、高可靠性和分布式特性,广泛应用于金融、互联网等领域。文章从环境搭建到消息类型的实战(普通消息、延迟消息、顺序消息和事务消息)进行了全面解析,并对比了三种消费者类型(PushConsumer、SimpleConsumer和PullConsumer)的特点与适用场景。最后总结了使用RocketMQ时的关键注意事项,如Topic和Tag的设计、监控告警的重要性以及性能与可靠性的平衡。通过学习本文,读者可掌握RocketMQ的使用精髓并灵活应用于实际项目中。
496 7
 一文带你从入门到实战全面掌握RocketMQ核心概念、架构部署、实践应用和高级特性
千万级数据秒级响应!碧桂园基于 EMR Serverless StarRocks 升级存算分离架构实践
碧桂园服务通过引入 EMR Serverless StarRocks 存算分离架构,解决了海量数据处理中的资源利用率低、并发能力不足等问题,显著降低了硬件和运维成本。实时查询性能提升8倍,查询出错率减少30倍,集群数据 SLA 达99.99%。此次技术升级不仅优化了用户体验,还结合AI打造了“一看”和“—问”智能场景助力精准决策与风险预测。
323 69
阿里云SLB深度解析:从流量分发到架构优化的技术实践
本文深入探讨了阿里云负载均衡服务(SLB)的核心技术与应用场景,从流量分配到架构创新全面解析其价值。SLB不仅是简单的流量分发工具,更是支撑高并发、保障系统稳定性的智能中枢。文章涵盖四层与七层负载均衡原理、弹性伸缩引擎、智能DNS解析等核心技术,并结合电商大促、微服务灰度发布等实战场景提供实施指南。同时,针对性能调优与安全防护,分享连接复用优化、DDoS防御及零信任架构集成的实践经验,助力企业构建面向未来的弹性架构。
316 76
|
21天前
|
微信读书十周年,后台架构的技术演进和实践总结
微信读书经过了多年的发展,赢得了良好的用户口碑,后台系统的服务质量直接影响着用户的体验。团队多年来始终保持着“小而美”的基因,快速试错与迭代成为常态。后台团队在日常业务开发的同时,需要主动寻求更多架构上的突破,提升后台服务的可用性、扩展性,以不断适应业务与团队的变化。
44 0
MCP 实践:基于 MCP 架构实现知识库答疑系统
文章探讨了AI Agent的发展趋势,并通过一个实际案例展示了如何基于MCP(Model Context Protocol)开发一个支持私有知识库的问答系统。
MCP 实践:基于 MCP 架构实现知识库答疑系统
IP代理技术原理深度解析:从基础架构到应用实践
IP代理是网络通信中的关键技术,通过构建中间层实现请求转发与信息过滤。其核心价值体现在身份伪装、访问控制和性能优化三个方面。文章详细解析了HTTP与SOCKS协议的工作机制,探讨了代理服务器从传统单线程到分布式集群的技术演进,并分析了在网络爬虫、跨境电商及企业安全等场景的应用。同时,面对协议识别、性能瓶颈和隐私合规等挑战,提出了多种解决方案。未来,IP代理将融合边缘计算、AI驱动优化及量子安全加密等趋势,持续发展为支撑现代互联网的重要基础设施。
156 2
基于 Next.js 的书法字体生成工具架构设计与 SSR 优化实践
本项目是一款书法字体生成工具,采用 Next.js 14(App Router)与 Tailwind CSS 构建前端,阿里云 Serverless 部署后端。通过混合渲染策略(SSG/SSR/CSR)、Web Worker 异步计算及 CDN 字体分片加载优化性能。服务端借助阿里云函数计算处理计算密集型任务,将平均耗时从 1200ms 降至 280ms,支持 1000+ QPS。动态路由与 ARMS 监控提升工程化水平,未来计划引入 WebGPU 和 AI 字体风格迁移技术,进一步优化用户体验。

热门文章

最新文章

AI助理

你好,我是AI助理

可以解答问题、推荐解决方案等

登录插画

登录以查看您的控制台资源

管理云资源
状态一览
快捷访问