微服务项目分层

一，起因

铁打的营盘流水的兵，在后人接手前人留下的项目时，经常咆哮一番，其中一个重要问题就是项目分层架构不清晰，分工不明确，可读性很差，没有办法维护和升级。经常出现推翻了重做，要不就忍着哪里出BUG补哪里。

 

二，经典分层

controller层为控制层，用来接受用户的请求。不会涉及太多的业务处理操作，一般交给service层来处理。

service层主要用来处理一些业务逻辑，不做任何的数据库操作。数据库操作交给dao层来处理。

dao数据访问层，与底层DB进行数据交换。

 

三，现状

随着业务的变大，用户的增多，必然造成系统的复杂性越来越大，这时候三层架构已不能完全够用。

比如系统除了给前端页面提供接口，还需要提供一些服务之间的调用接口，甚至开放给第三方调用。

而且当下微服务盛行，微服务需要彼此调用，甚至依赖第三方接口，这些既不属于业务层也不属于数据库层。

 

四，新分层架构

 

facade作为对外接口定义层，这样能够很好满足单一职责原则和接口隔离原则，可以区别定义页面接口，和对外开发接口，然后由controller层实现，其实这也是面向对象思想的接口编程原则，DTO是为了网络传输定义的对象。这样还可以把Swager的注解放在这一层，防止对业务代码的侵蚀。

 

biz作为业务逻辑层，在这一层可以对DTO参数进行转义为实体Entity，以及业务逻辑的处理，DTO和Entity转义可以参考《DTO与entity转化》。

 

client作为调用第三方接口封装层，包括其他服务的http接口，基础平台，并对第三方的传递参数做DTO封装，做异常捕获处理，负载，熔断，都在这一层配置。

 

这样我们会弱化controller层，做到简单明了，可读性高，同时在这一层做异常拦截，因为这个做为最外层需要把捕获的异常转义为ErrorCode和Message，所以异常处理在这一层。

 

service层更加专注于对数据的校验上，数据函数处理，缓存中间处理，多张表的事务处理，来减轻数据库对数据处理的压力，所以事务处理在这一层。

当然项目中还会有其他层，比如：util层，common层，exception层等，这些可作为项目附加层，酌情处理。

 

五，总结

关于项目分层，仁者见仁，智者见智，无论如何分层，希望大家的有一个共识，统一规范，这样你的项目才会越走越远。

 

如果你喜欢，欢迎关注我的公众号！