系列文章目录

01 | 使用Gradle构建多模块项目
02 | 架构师必备 - DDD领域驱动设计之落地实践
03 | 异常处理实践 - 抛异常+错误码

上一讲，我们使用 Gradle 构建了多模块项目 Yanx ，接下来，说一下我所采用分层设计。

请看今天的第2讲：SpringBoot 中的 DDD 领域驱动设计。

前言

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

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

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

DDD的优势

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

翻阅了很多关于 DDD 的文章，大多数是理论知识，翻来覆去的就是一些名词：战略设计、战术设计、核心域、支撑域、值对象、实体、聚合… 但是实际落地还是不尽如人意，下面介绍下我在 Yanx 中应用 DDD 的落地方案。

DDD分层

层次说明

讯享网

最外面的一层是 api、command、query、domain、infra、model ，下面分别介绍：

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

分层及调用关系

层与层之间的关系，以及模型传递说明：

详细说明：

• 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)); } } 

1. 在 BaseApi 中封装了两个命令执行类 queryExecutor 和 commandExecutor ，调用应用层时执行不同的命令即可，无需 @Autowired 引入不同的服务
2. @ApiResult 加上这个自定义注解后，对返回结果统一封装
3. @Pagination 加上这个自定义注解后，会自动将分页参数存入线程变量，后面查询时也会自动获取分页参数，返回结果统一封装时也会加上分页信息
4. Qo 是查询参数对象， Dto 是增删改等命令参数对象，返回对象为 Vo ，这里要注意，Entity 绝对不能暴露到这一层，需要转换为 Vo 再返回
5. 在这一层中，每个方法几乎就是一行执行命令的语句，一般情况不进行业务逻辑（当然也有特殊情况咯）

• command包

讯享网@AllArgsConstructor public class SysUserAddCmd implements Command<Void> { 
    private SysUserDto sysUserDto; @Override public Void execute(Executor executor) { 
    // 获取命令的接收者：领域服务 SysUserManager receiver = executor.getReceiver(SysUserManager.class); // 对象模型转换，由DTO转为Entity，使用了MapStruct SysUser sysUser = SysUserMapper.INSTANCE.toSysUser(sysUserDto); // 使用JPA保存 receiver.save(sysUser); return null; } } 

1. 增删改命令，很薄的一层，作为一项工作的组织者，几乎没有业务逻辑，调用领域服务和充血对象方法
2. 命令模式，实现自定义 Command 接口，泛型为返回值
3. 通过属性和构造方法（使用 lombok 注解）接收参数
4. 一个命令里只有一个 execute 方法，缺点是会产生大量的命令类，一个类相当于之前 service 类中的一个方法，但是这样符合了单一职责原则
5. 通过 executor.getRecerver 方法获取到领域服务（manager）
6. DTO 绝对不在领域层中使用 ，需要先由 DTO 转换为 Entity （转换方法这里使用的 MapStruct ，以后再单独细讲）

• query包

@AllArgsConstructor public class SysUserByIdQry extends QryCommand<SysUserVo> { 
    private Long id; @Override public SysUserVo execute(Executor executor) { 
    if (id == null) { 
    throw new BusinessException("用户ID不能为空"); } QSysUser sysUser = QSysUser.sysUser; return queryFactory.select(this.fields()) .from(sysUser) .where(sysUser.deleted.eq(false), sysUser.id.eq(id)) .fetchOne(); } / * 用户VO映射 * * @return QBean<SysUserVo> */ public static QBean<SysUserVo> fields() { 
    QSysUser sysUser = QSysUser.sysUser; return Projections.fields( SysUserVo.class, sysUser.username, sysUser.nickname, sysUser.status, sysUser.email, sysUser.phone, sysUser.avatar, sysUser.deptId, sysUser.id ); } } 

1. 命令模式，继承自定义 QryCommand 基类（此类也实现了自定义的 Command 接口，其中引用了 QueryDSL 的 queryFactory 类，且封装了分页方法），泛型为返回值
2. query 包中的查询命令与 command 包中的命令大体相同，唯一区别是 query 命令理论上直接查询数据库，不调用领域层
3. 由于JPA对于复杂查询不太好用，这里强烈推荐使用 QueryDSL （以后再单独细讲），图中是一个简单的使用例子

• domain包

类较多，这里不一一罗列：

1. 由 Entity 类自动生成数据库表，仅维护 Entity 类（屏蔽数据库）
2. 设计 Entity 时根据实际业务灵活使用 @OneToMany、@OneToOne 等注解（聚合根的概念）
3. 聚合根不要太大，80%的情况一个聚合根中只包含一个实体（不要过度设计成大聚合根）
4. 不要使用贫血模型，一定要面向对象，将属于对象的方法要放到对象中，但是对象中不建议引入仓库 Repository 类，需要操作数据库的方法写在领域服务 manager 里
5. 业务逻辑尽量写在领域服务（manager）中，不断提取、抽象不同的方法供应用层调用
6. 适当的使用领域事件， JPA 可以在 Entity 中使用 @DomainEvents 注解来发送领域事件

心得

1. DDD 不是银弹，对于简单的功能，使用三层架构更便捷清晰。
2. 通过 DDD 对业务理解更加透彻，写的代码可以更好的传达客户的业务诉求。
3. 能够尽情的编写低耦合的、符合单一职责、开闭等原则、封装、继承、多态的代码，是很身心愉悦的。
4. 前期相比传统架构代码量更多，开发人员前期投入更多：
   • 领域的合理划分、实体的合理设计
   • 大量的DTO、VO等数据对象
   • 大量的数据对象转换方法
   • 大量的命令类
   • …

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

最后

上面简单介绍了下我对 DDD 的理解和实践，并通过实际的代码展现了如何在 SpringBoot 中应用 DDD ，希望能够给大家提供一个思路。项目代码已托管到 Gitee（搜索 yanx ），大家可自行下载学习，如果有什么问题请在下方留言。