说起应用分层，大部分人都会认为小Case，不就是Web应用常用的三层架构嘛，上层依赖下层，分为：Controller（Web层）、Service（业务层）、 Dao（数据层）。看起来简单，很多人其实并没有把他们职责划分开，在很多代码中，Controller做的逻辑比Service还多，Service往往当成透传了，这其实是很多人日常开发都没有注意到的地方，反正功能也能用，至于放哪无所谓呗。这样往往造成后面代码无法复用，层级关系混乱，对后续代码的维护非常麻烦。
的确在这些人眼中分层只是一个形式，前辈们的代码这么写的，其他项目代码这么写的，那么我也这么跟着写。但是在真正的团队开发中每个人的习惯都不同，写出来的代码必然带着自己的标签。有的人习惯Controller写大量的业务逻辑，有的人习惯在Service中之间调用远程服务，这样就导致了每个人的开发代码风格完全不同，后续其他人修改的时候，看了一眼，非常嫌弃这个人写的代码和我平常的习惯完全不同。现实很残酷啊！修改的时候到底是按着自己以前的习惯改，还是跟着前辈们走呢？这又是个艰难的选择，选择一旦有偏差，你的后辈又维护你的代码的时候，恐怕就要骂人了。
所以一个好的应用分层需要具备以下几点:
- 方便后续代码进行维护扩展。
- 分层的效果需要让整个团队都接受。
- 各个层职责边界清晰。
阿里分层规范
：可直接封装 Service 方法暴露成 RPC 接口；通过 Web 封装成 Http 接口；进行 网关安全控制、流量控制等。
：各个端的模板渲染并执行显示的层。当前主要是 Velocity 渲染，JS 渲染， JSP 渲染，移动端展示等。
主要是对访问控制进行转发，可以是视图转发或者JSON数据响应。各类基本参数校验，或者不复用的业务简单处理等。
：相对具体的业务逻辑服务层。
：通用业务处理层，它有如下特征:
- 对第三方平台封装的层，预处理返回结果及转化异常信息。
- 对Service层通用能力的下沉，如：缓存方案、中间件通用处理。
- 与DAO层交互，对多个DAO的组合复用。
：数据访问层，与底层 MySQL、Oracle、Hbase、Redis、ES等进行数据交互。
阿里巴巴规约中的分层比较清晰简单明了，但是描述得还是过于简单了，以及Service层和Manager层有很多同学还是傻傻分不清它们之间的关系，就导致了很多项目中根本没有Manager层的存在。下下一节，将介绍一下具体业务中应该如何实现分层。
现在给出一个比较理想的模型，使用RPC框架为例，我们选用的是Thrift（下文统称：TService）可能会比其他的一些RPC框架，例如：Dubbo会多出一层，作用与Web层的Controller类似。
理想的分层模型
最上层Controller和TService是阿里分层规范里面的第一层：轻业务逻辑，参数校验，异常兜底。通常这种接口可以轻易更换接口类型，所以业务逻辑必须要轻，甚至不做具体逻辑。
：业务层，复用性较低，推荐Web层每一个Controller方法都仅对应一个Service，不要把业务逻辑放在Web层的Controller中去实现。业务逻辑都放到Service去实现，为什么呢？如果我们把业务实现放在Web层的Controller层去实现的话，如果以后我们要接入Thrift，那么这里又需要把相同的业务实现在做一次，这样会导致我们每接入一个入口层的这个代码都得重新复制一份，如下图所示:
分层现状
现有实现，业务实现存在于Web层Http协议访问的CrmController，我们现在需要对该业务新增RPC协议支持，瓦塔西！直接在RPC实现调用HTTP远程服务不合理需要复制远程服务相同逻辑改造外，而且还需要将现有CrmController已实现的完全相同的逻辑，再在CrmThriftService实现一次。大量的重复工作必定会导致我们开发效率及应用可扩展性下降，所以我们需要把业务逻辑实现都得放进Service中去做：
优化后的分层
：可复用逻辑层。这里的Mannager可以是单个服务实现，比如：我们的Cache，MQ等等。当然也可以是复合的，当你需要调用多个Mannager的时候，这个可以合为一个Mannager，比如逻辑上的连表查询等。如果是HttpMannager或RpcMannager需要在这一层做一些数据转换。
：数据库访问层。主要负责“操作数据库的某张表，映射到Java中的DO对象”，Dao应该只允许自己的Service访问，其他Service要访问我的数据必须通过对应的Service进行访问。
我们的编码规定义了下面几个领域模型规约：
-
DO（Data Object）：与数据库表结构对应，通过Dao层向上传输数据源对象。
-
DTO（Data Transfer Object）：数据传输对象，Service（Dubbo服务 / RPC服务）或Manager向外传输的对象。
-
BO（Business Object）：业务对象。由Service层输出的封装业务逻辑的对象。
-
AO（Application Object）：应用对象。在Web层与Service层之间抽象的复用对象模型，极为贴近展示层，复用度不高。
-
VO（View Object）：显示层对象，通常是Web层向模板渲染引擎层或视图层传输的对象。
-
Query：数据查询对象，Web层接收调用方的查询请求。注意超过2个参数的查询封装，禁止使用Map类来传输。
-
Update：数据更新对象，Web层接收调用方的更新数据请求。
-
Form：新增数据对象，Web层接收调用方的新增数据请求。
：
| 层次 | 领域模型 |
|---|---|
| Controller / TService | VO / DTO |
| Service（Dubbo服务 / RPC服务） / Manager | AO / BO |
| Dao | DO |
每一个层基本都自己对应的领域模型，这样就导致了我们过于追求每一层都是用自己的领域模型。这样会导致在一次请求中，一个对象可能会出现3次甚至4次转换，当返回的时候同样也会出现3-4次转换，这样有可能一次完整的请求返回的过程，会出现很多次对象转换。在开发中通过实践证明，如果真的按照这么来操作，恐怕就别写其他的了，一天就光写这个重复无用的转换逻辑算了吧！
：
- 允许Service（Dubbo服务 / RPC服务） / Manager可以操作数据领域模型（DO），对于这个层级来说，本来自己做的工作也是做的是业务逻辑处理和数据组装。
- Controller / TService层的领域模型不允许传入Dao层，因为这样就不符合职责划分了，所以必须转换为DO传入Dao层。
- 同理，不允许Dao层的数据传入到Controller / TService。
：
| 层次 | 领域模型（入参） | 领域模型（返回） |
|---|---|---|
| Controller / TService | Query / Update / Form | VO |
| Service（Dubbo服务 / RPC服务） / Manager | Query / Update / Form | VO |
| Dao | DO | DO |
领域模型层次规范
总体来说业务分层对于代码规范是比较重要，决定着以后的代码是否可复用，是否可扩展，是否职责清晰，边界清晰。
当然这种分层其实仁者见仁，智者见智，团队中的每个成员的分层习惯也不同，所以很难权衡出一个标准的准则，总的来说只要满足职责逻辑清晰，后续维护容易，就是好的分层。
结束前的话，如果你的团队有更好的分层，或者上面所描述的存在什么错误，不合理，更好的方式，还请留言指正交流一下。
网友评论