DDD分层架构的应用

开篇

• 上周有机会去上海参加了2021年的架构师峰会，分享中提到了很多云原生的概念，但是云原生的概念更多适合云厂商而非业务相关的开发。作为业务开发的我更关注的是业务相关的分享，也就是这次分享中的DDD相关的概念。

• DDD有很多概念，包括通用语言、实体、Repository、分层架构等等，这次主要总结的是分层架构和实体定义。DDD是一个仁者见仁智者见智的概念，很多东西都可以直接往上套。

• 这次分享给我最大的感触就是没有为了DDD而DDD，而是运用其中提到的分层架构来解决实际遇到的问题，而这种解决方案是比较有参考性和落地意义的。

架构规范

• 业务开发的整体架构规范如上图所示，整体的访问是从左到右。
• 从架构维度的分层为Interface层、application层、domain层、infrastructure层。
• Interface层接收和转化参数访问application层，响应application层返回值进行返回。
• Application层负责串联业务流程，通过Domain层的Service来完成业务处理。
• Domain层负责以领域模型的划分处理具体的业务。
• Infrastructure层作为基础设施层，主要封装第三方业务访问包含MQ数据库RPC等。

对比我们日常spring mvc模式的分层架构，我们能够发现本质上MVC就是在践行DDD的分层架构，但不是每个使用mvc分层架构的实现都有明确的分层边界定义，不是每个使用mvc分层架构的实现都定义了每层使用的领域对象。

所以在原来的基础上定义每层的业务边界和数据边界就是更好的应用分层实现业务扩展

分层架构

服务层定义

• 服务对外提供的接口包括面向web client的rest接口或者面向rpc client的dubbo接口。我们定义Controller为对应的Api Layer（Interface层），Api层负责接收请求并交由Service层进行处理。
• Service层包含Application和Domain两个维度的Service，Application Service主要是负责业务流程的编排，Domain Service负责具体业务的处理，但是根据具体业务的复杂性我们可能只有Application Service而没有Domain Service，但是建议包含Domain Service。
• Persist Layer或者Rpc Layer可以映射为Infrastructure层，主要用来访问DB或者外部的rpc服务，为了屏蔽底层差异新增的屏蔽层。

数据层定义

• Api层对外定义参数变量Param，对Service层转化为DO/BO对象，负责Param到DO/BO的转换。
• Service层对Api层定义DO/BO对象，对Persist/Rpc层定义PO/DTO对象，对内负责DO/BO到PO的转换，对外负责DO/BO到VO/DTO的转换。
• Persist/Rpc层对Service定义PO/DTO对象，对外PO/DTO到DO/BO的转换。
• 不同层定义了的参数之间相互转换通过MapStruct来实现降低成本。
• 从分层依赖的角度来看上层依赖于下层，因此数据对象定义应该在下层进行定义；上层传给下层的数据由上层负责转换，下层传给上层的数据由下层负责转换。

Api层异常处理

• 通过切面来解决Spring Mvc返回结果的异常处理，通过Filter来解决Dubbo返回结果的异常处理。

@PostMapping("checkout")
public Result<OrderDTO> checkout(Long itemId, Integer quantity) {
    try {
        CheckoutCommand cmd = new CheckoutCommand();
        OrderDTO orderDTO = checkoutService.checkout(cmd);    
        return Result.success(orderDTO);
    } catch (ConstraintViolationException cve) {
        // 捕捉一些特殊异常，比如Validation异常
        return Result.fail(cve.getMessage());
    } catch (Exception e) {
        // 兜底异常捕获
        return Result.fail(e.getMessage());
    }
}

• Controller层所有Api接口都有重复的异常处理逻辑，代码重复率极高。
• 通过自定义注解和切面来优化代码逻辑，Api层只包含正常的业务处理流程。

@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
public @interface ResultHandler {

}

@Aspect
@Component
public class ResultAspect {
    @Around("@annotation(ResultHandler)")
    public Object logExecutionTime(ProceedingJoinPoint joinPoint) throws Throwable {
        Object proceed = null;
        try {
            proceed = joinPoint.proceed();
        } catch (ConstraintViolationException cve) {
            return Result.fail(cve.getMessage());
        } catch (Exception e) {
            return Result.fail(e.getMessage());
        }
        return proceed;
    }
}

• 切面统一封装异常的处理的流程。

总结

• 目前我对于DDD的理解更多是在分层的理念上，从外到层依次氛围Api层、Application Service层、Domain Service层、Repository层、Infrastructure层。

• 相比较传统spring mvc的三层架构，为了分层的更加明确性DDD做了更多的细化。针对Service层拆分为了Application Service层和Domain Service层，Domain Service负责处理特定域的服务，Application Service层负责通过Domain Service进行业务流程编排；针对数据访问层或者外部的Rpc服务调用层，我们增加了Repository来进行依赖隔离。

• 明确了每层的数据边界和数据转换的方法，各层数据包含Param+DO+VO+PO等。通过MapStruct降低数据转换的成本，也利于提高我们分层定义对象的积极性。

参考

• 感谢架构师峰会殷浩的分享收货颇多，准备去分享并推广，提高大家的代码效率。