先看一段简单的代码:
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中有限界上下文,而且限界上下文之间需要高度自治、隔离变化,防腐层因运而生。
而这儿的LoginRequest就是两个限界上下文的通信数据,而核心业务层是有对应的业务对象承接数据。
这样有常见的两个问题
《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,既方便,性能也高效。
比如创建文章,编辑文章,两者入参差不多,只是创建时没有id,而编辑时有id,从代码复用角度,不想类的膨胀,DTO只创建一个。会出现一个dto会有很多很多的属性。
但从业务语义角度,两个业务行为就不应该共用同一个对象。需要有CreateArticleCmd和EditArticleCmd
而对于request dto的数量,从友好API角度,应该要有两个DTO,但如果是复杂的查询操作,query dto属性数量比command dto更多些。
clean code,这篇主要阐述了分层架构中传输对象与业务对象职责不清问题。
应对策略:
大到一个微服务,小到一个变量,SRP原则无处不在。
DTO属性要明确简单,业务对象要语义清晰显现化。
[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