一文轻松带你上手领域驱动设计（DDD）|架构师必备（一）

【直播预告】替代 Oracle，我们还有多长的路要走？

前言

在日常工作中，接手或维护的工程，大多数使用的是三层架构，即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，希望能为大家提供一个思路。

本文由博客一文多发平台 OpenWrite 发布！

OpenAI 面向所有用户免费开放 ChatGPT Voice 程序员篡改 ETC 余额，一年私吞 260 余万元 Spring Boot 3.2.0 正式发布 谷歌员工离职后抨击大老板，曾深度参与 Flutter 项目、制定 HTML 相关标准 微软 Copilot Web AI 将于12月1日正式上线，支持中文 微软开源 Terminal Chat Rust Web 框架 Rocket 发布 v0.5：支持异步、SSE、WebSockets 等 Redis 之父用纯 C 语言代码实现 Telegram Bot 框架 假如你是开源项目维护者，遇到这种回复能忍到哪步？ PHP 8.3 GA

{{o.name}}

{{m.name}}