你好，欢迎收听极客视点。
说起应用分层，大部分人都会认为这不是很简单嘛，就Controller、Service、Mapper三层。但在“简单”背后，很多人并没有将各层级的职责划分清楚。比如在很多代码中，Controller比Service还多，Service被当成透传了，这是开发代码容易被忽略的地方。这样往往造成层级关系混乱，后续代码无法复用、维护困难。
此前，公众号“咖啡拿铁（ID：close_3092860495）”介绍了优化代码分层的方法，供你参考。
如何进行分层
一个好的应用分层需要具备以下几点：
- 方便后续代码进行维护扩展；
- 分层的效果需要让整个团队都接受；
- 各层的职责边界清晰。
阿里巴巴的分层规范
在阿里的编码规范中，对分层的要求如下：1. 开放接口层：可直接封装 Service 方法暴露成 RPC 接口；通过 Web 封装成 http 接口；进行网关安全控制、流量控制等。
2. 终端显示层：各个端的模板渲染并执行显示的层。当前主要是 velocity 渲染、JS 渲染、JSP 渲染、移动端展示等。
3. Web 层：主要是对访问控制进行转发，各类基本参数校验，或者不复用的业务简单处理等。
4. Service 层：相对具体的业务逻辑服务层。
5. Manager 层：通用业务处理层，它有如下特征：一是对第三方平台封装的层，预处理返回结果及转化异常信息；二是对Service层通用能力的下沉，如缓存方案、中间件通用处理；三是与DAO层交互，对多个DAO的组合复用。
6 .DAO 层：数据访问层，与底层 MySQL、Oracle、Hbase 进行数据交互。
阿里巴巴规约中的分层比较清晰，简单明了，但是描述得还是过于简单了，很多人还是分不清楚Service层和Manager层之间的关系，导致很多项目中根本没有Manager层的存在。下面介绍具体业务中应该如何实现分层。
优化分层
首先需要说明的是，如果RPC框架选用Thrift，可能会比其他的RPC框架多出一层，作用和Controller层类似：
其次是Service层，这是业务层，复用性较低，这里推荐每一个Controller方法都对应一个Service，不要把业务编排放在Controller中去做，否则以后你要接入Thrift，又需要把业务编排再做一次，这会导致你每接入一个入口层，代码都得重新复制一份。如下图所示：
这样大量的重复工作必定会导致开发效率下降，所以你要把业务编排逻辑都放进Service层中。 
再来看DAO层，这是数据库访问层。主要负责“操作数据库的某张表，映射到某个Java对象”，DAO应该只允许自己的Service访问。
最后顺便聊一聊分层领域模型的转换，在阿里巴巴编码规约中，列举了下面几个领域模型规约：
- DO（Data Object）：与数据库表结构一一对应，通过DAO层向上传输数据源对象。
- DTO（Data Transfer Object）：数据传输对象，Service或Manager向外传输的对象。
- BO（Business Object）：业务对象，由Service层输出的封装业务逻辑的对象。
- AO（Application Object）：应用对象，在Web层与Service层之间抽象的复用对象模型，极为贴近展示层，复用度不高。
- VO（View Object）：显示层对象，通常是Web向模板渲染引擎层传输的对象。
- Query：数据查询对象，各层接收上层的查询请求。注意超过2个参数的查询封装，禁止使用Map类来传输。
每一个层基本都有自己对应的领域模型，而有些人过于追求每一层都用自己的领域模型，这就导致在一次请求中，出现多次对象转换。一个折中的方案是：
- 允许Service/Manager可以操作数据领域模型。
- Controller/TService层的领域模型不允许传入DAO层，这样就不符合职责划分了。
- 同理，不允许DAO层的数据传入到Controller/TService。
总结
业务分层对于代码规范是比较重要的，决定后续代码是否可复用，是否职责清晰、边界清晰。
以上就是今天的内容，如果你的团队有更好的分层方法，欢迎留言分享。
