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

哈喽，大家好，我是啾啾。

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

前言

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

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

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

DDD

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

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

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

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

落地方案

1、代码分层

image.png

代码分层

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

2、层级关系及模型传递

image.png

分层及调用关系

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 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 {

    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 {

    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
     */
    public static QBean 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，希望能为大家提供一个思路