Author: caffe latte
layer your code, for any Java developer it should not unfamiliar. A good level classification can not only make the code more clear structure, you can also make the project more clear division of labor, greatly enhance readability, more conducive to the maintenance and upgrade later.
From another perspective, the good code layered architecture, should be a good match on the principle of single responsibility. This can reduce the dependence between the layers, but also the maximum degree of multiplexing logic layers. This article describes how in the end should be layered source Java project under.
1. Background
Speaking layered application, most people will agree that this is not a very simple thing to controller, service, mapper three. Looks simple, in fact, a lot of people do not open their segregation of duties, in a lot of code, controller logic to do more than the service, service is often as a pass-through, and this is actually a lot of people are not aware of the development code of the place, anyway function can also be used, which does not matter as to put chant. This often causes behind the code can not be reused, hierarchy confusion, follow-up maintenance of the code is very troublesome.
In the eyes of these people really just a form of stratification, predecessors of the code written so other project code written so, so then I have to follow to write. But in the real team in the development of each person's habits are different, write code that is bound with his own label, some people used to write a lot of business logic controller, some people used to call a remote service between service, so everyone has led to the development of the code completely different style, follow others modified, look, I rely on this person to write code and completely different from my usual habit, modify the time in the end in his own previous habits change, or follow the predecessors to go, this is a difficult choice, selection bias once, your younger and maintain your code, probably would curse.
So a good layered application requires the following:
facilitate subsequent maintenance code extension.
Layered effect need to get the whole team to accept
individual responsibility clear boundary layer
2. How stratified
Ali 2.1 specification
constraints in the hierarchical coding standards Ali follows:
Open Interface Layer : Service packaging method of directly exposed to RPC interface; http encapsulated into a Web interface; a gateway for security control and flow control.
Terminal display layers : a template layer exhibits render and execute the respective ends. The main current is velocity rendering, JS rendering, JSP rendering, display and other mobile terminal.
Web layer : mainly for access control forwarding, all kinds of basic parameters check, business or simple treatment no longer used.
Service layer : a relatively specific business logic services layer.
Layer Manager : General business process layer, which has the following characteristics: 1 layer of the third-party platform package, and return the results pre-conversion abnormality information; generic capability to sink 2 Service layer, such as caching scheme, generic middleware. processing;.. 3 DAO layer interacts with the combination of multiplexing a plurality of DAO.
DAO layer : data access layer, data interaction with the underlying MySQL, Oracle, Hbase.
Stratified statute of Alibaba relatively clear and simple and clear, but the description was still too simple, and the service layer and layer manager could not tell many students still somewhat the relationship between, has led to many projects do not have layers Manager presence. Here's how specific businesses should implement tiered
2.2 optimized hierarchical
summary of a more ideal model from our business development, we must first explain here what rpc because of our framework of choice is likely to thrift than some other rpc for example, the frame will be more dubbo layer, controller layer, and a similar effect
最上层controller和TService是我们阿里分层规范里面的第一层:轻业务逻辑，参数校验，异常兜底。通常这种接口可以轻易更换接口类型,所以业务逻辑必须要轻，甚至不做具体逻辑。
Service：业务层，复用性较低，这里推荐每一个controller方法都得对应一个service,不要把业务编排放在controller中去做，为什么呢？如果我们把业务编排放在controller层去做的话，如果以后我们要接入thrift,我们这里又需要把业务编排在做一次，这样会导致我们每接入一个入口层这个代码都得重新复制一份如下图所示: 
这样大量的重复工作必定会导致我们开发效率下降，所以我们需要把业务编排逻辑都得放进service中去做: 
Mannager：可复用逻辑层。这里的Mannager可以是单个服务的，比如我们的cache,mq等等，当然也可以是复合的，当你需要调用多个Mannager的时候，这个可以合为一个Mannager，比如逻辑上的连表查询等。如果是httpMannager或rpcMannager需要在这一层做一些数据转换
DAO：数据库访问层。主要负责“操作数据库的某张表，映射到某个java对象”，dao应该只允许自己的Service访问，其他Service要访问我的数据必须通过对应的Service。
3.分层领域模型的转换
在阿里巴巴编码规约中列举了下面几个领域模型规约:
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类来传输。
层次领域模型Controller/TServiceVO/DTOService/ManagerAO/BODAODO
每一个层基本都自己对应的领域模型，这样就导致了有些人过于追求每一层都是用自己的领域模型，这样就导致了一个对象可能会出现3次甚至4次转换在一次请求中，当返回的时候同样也会出现3-4次转换，这样有可能一次完整的请求-返回会出现很多次对象转换。如果在开发中真的按照这么来，恐怕就别写其他的了，一天就光写这个重复无用的逻辑算了吧。
所以我们得采取一个折中的方案:
1.允许Service/Manager可以操作数据领域模型，对于这个层级来说，本来自己做的工作也是做的是业务逻辑处理和数据组装。
2.Controller/TService层的领域模型不允许传入DAO层，这样就不符合职责划分了。
3.同理，不允许DAO层的数据传入到Controller/TService.
4.总结
Overall business is more important for hierarchical coding standards, determine whether future reusable code, whether clear responsibilities, clear boundary.
Of course, this is actually a matter of opinion layered, layered habit of all the team is different, it is difficult to weigh out the guidelines for a standard, general duties as long as logical, easy to follow-up maintenance is good stratification.
Finally, if your team has a better stratification, or what's wrong with the place described above also correct me please leave a message.
Welcome to share with everyone, like the point of a praise yo remember the article, thanks for the support!