Clean Code系列之DDD分层参数转换

先看一段简单的代码：

package com.zhuxingsheng.adapter

@PostMapping("/login")
public LoginResponse login(LoginRequest loginRequest) {

    return loginService.login(loginReqeust);

}

从代码中，可以明显看出这是一段处理登陆请求的方法。在大多数项目中，这种代码很常见。

它有什么坏味道呢？

分层穿透了，LoginRequest类本应该属于入口层，结果穿透到了service层。

细细追究，需要明确的问题：

1、LoginRequest到底属于哪一层，是resource层，还是service层？

2、没有达到DDD防腐层的意义，resource是隔离外部与核心业务的，但却变成了透传。

归属哪一层

在《再议DDD分层》中，也讨论过。

当前系统是以REST方式对外提供服务，如果后面需要以RPC方式对个提供服务，显示LoginRequest可能不再适用。

从图中可以看出REST方式是Controller，而如果是thrift方式是TService。controller的LoginRequest参数，会在TService中失效。在实现层面，LoginRequest本质上就是个DTO，传输数据。而且不再像过去原始servlet，传输数据时会有很多原生API类型，现在的框架都进化了，request对象中只有业务属性。

从这个角度讲，request对象是在resource层，并且是与各个实现框架绑定的。

另外，resource层还需要处理request参数的检验与转换。如果直接透传到service层，不仅加重了service的职责，而且对于service层，我们更推荐使用ADT方式，让代码更有业务语义，不使用单纯的技术基础类型。

总结一下整体结构就是这样：

DDD防腐层

DDD中有限界上下文，而且限界上下文之间需要高度自治、隔离变化，防腐层因运而生。

而这儿的LoginRequest就是两个限界上下文的通信数据，而核心业务层是有对应的业务对象承接数据。

这样有常见的两个问题

1、代码重复

《DDD实战指南》中提出，我们引入CQRS架构中的概念，业务层有对应cmd和query对象。

如LoginRequest到LoginCmd转换，但两个类的内容都一样

package com.zhuxingsheng.adapter.pl

public class LoginCmd {
    private String username;
    private String password;
}

如果是这样，那我们参数校验逻辑是不是得写到service里面，不然校验逻辑也要重复了。

当测试代码时，controller的测试与service的测试是一致的，use case是相同的。

怎么应对，还是上文提到的ADT方式，对于service层，不再提倡使用技术层面的基本类型，如username属性包装成Username类，而校验逻辑可以封装在Username中

package com.zhuxingsheng.adapter.pl

public class Username {
    private String username;
    
    public Username(String username) {
        if (username == null) {
            throw   new ValidationException("username不能为空");
        } else if (isValid(username)) {
            throw   new ValidationException("username格式错误");
        }
        this.username = username;
    }
    
}

这样对于service层的方法业务语义更加显现化。

public void login(Username username,Password password) {
    
}

对于login方法的测试，use case数量相对基础类型也变少了。

对于复杂对象的转换，可以使用mapstruct，既方便，性能也高效。

2、代码复用

比如创建文章，编辑文章，两者入参差不多，只是创建时没有id,而编辑时有id，从代码复用角度，不想类的膨胀，DTO只创建一个。会出现一个dto会有很多很多的属性。

但从业务语义角度，两个业务行为就不应该共用同一个对象。需要有CreateArticleCmd和EditArticleCmd

而对于request dto的数量，从友好API角度，应该要有两个DTO，但如果是复杂的查询操作，query dto属性数量比command dto更多些。

总结

clean code，这篇主要阐述了分层架构中传输对象与业务对象职责不清问题。

应对策略：

大到一个微服务，小到一个变量，SRP原则无处不在。

DTO属性要明确简单，业务对象要语义清晰显现化。