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分层》[1]中，也讨论过。
当前系统是以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实战指南》[2]中提出，我们引入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属性要明确简单，业务对象要语义清晰显现化。
References
[1] 《再议DDD分层》: https://www.zhuxingsheng.com/blog/further-discussion-on-ddd-layering.html
[2] 《DDD实战指南》: https://www.zhuxingsheng.com/blog/ddd-tactical-practice-guide.html