If you like reading wechat and want to know more about Java knowledge, system design, distributed middleware, etc., you can follow my wechat: Coffee latte, of course, there are more benefits waiting for you.

1. The background

When it comes to application layering, most people think it’s not that easy: Controller, Service, mapper. In most code, controllers do more logic than services. Services tend to be considered pass-through. This is something that most people don’t notice when they’re developing code. This often leads to the subsequent code can not be reused, hierarchical relationship chaos, the maintenance of the subsequent code is very troublesome.

It’s true that in the eyes of these people, layering is just a formality. The code of previous generations is written this way, and the code of other projects is written this way, so I will write this way. But in the real team development everyone is different, the habit of writing code is bound to bring your own tags, some people used to the business logic controller to write a lot of, some people habit between calls to the remote service in the service, thus led to the development of each person code style is completely different, following others change, a look, I relied on this person to write code and I am totally different from the usual habits, when the change in the end should be according to their own habits, or follow the predecessors, this is a difficult choice, once the choice is wrong, your descendants and maintain your code, I am afraid you will curse.

So a good application layering requires the following:

• Convenient follow-up code maintenance extension.
• The effect of layering needs to be accepted by the entire team
• The boundaries of responsibility are clear

2. How to layer

2.1 Ali Specification

The hierarchy of constraints in Ali’s coding specification is as follows:

Open interface layer: encapsulate Service methods directly and expose them as RPC interfaces. Through Web encapsulation into HTTP interface; Performs gateway security control and traffic control.

Terminal display layer: The layer in which the template is rendered and displayed at each end. Currently, velocity rendering, JS rendering, JSP rendering, mobile display and so on.

Web layer: forwards access control, verifies various basic parameters, or handles simple services that are not reused.

Service layer: Relatively specific business logic Service layer.

Manager layer: a general business processing layer, which has the following characteristics :1. The layer of third-party platform encapsulation, preprocessing returned results and transforming abnormal information; 2. 2. Subtraction of the general capabilities of the Service layer, such as caching schemes and middleware general processing; 3. Interact with DAO layer and reuse multiple DAO combinations.

DAO layer: data access layer, which interacts with low-level MySQL, Oracle, and Hbase.

The layers in The Alibaba protocol are clear and simple, but the description is still too simple, and many students are still confused about the relationship between the service layer and the Manager layer, which leads to the fact that there is no Manager layer in many projects. Here is how to achieve layering in specific business

2.2 Optimized Layering

To summarize an ideal model from our business development, it is important to note that due to thrift’s CHOICE of RPC framework, there may be one more layer than some other RPC frameworks such as Dubbo, which acts like the Controller layer

1. The top layer of Controller and TService is the first layer in our Ali layering specification: light business logic, parameter validation, exception cover. Usually, the interface can be easily changed, so the business logic must be light, or even not concrete logic.

2.Service: Business layer, low reuse, here recommended that each controller method correspond to a Service, do not put business orchestration in the controller, why? If we put the business orchestration in the Controller layer, and if we want to add thrift in the future, we need to do the business orchestration again. This will cause the code to be copied every time we access the entry layer as shown in the figure below:

This amount of rework is bound to lead to a reduction in development efficiency, so we need to put all the orchestration logic into the service:

3.Mannager: Reusable logical layer. A Mannager can be a single service, such as cache, MQ, etc., or it can be a compound one. If you need to call multiple Mannagers, this can be combined into a single Mannager, such as logical table query, etc. If httpMannager or rpcMannager needs to do some data conversion at this layer

DAO: Database access layer. The dao should only allow its own services to access my data. Other services must go through the corresponding Service to access my data.

3. Transformation of hierarchical domain model

The following domain model specifications are listed in the Alibaba coding specification:

• DO (Data Object) : Corresponds to the database table structure one by one, and transmits Data source objects upward through the DAO layer.
• Data Transfer Object (DTO) : A Data Transfer Object, such as a Service or Manager, that is transmitted externally.
• Business Object (BO) : Business Object. An object that encapsulates business logic output by the Service layer.
• Application Object (AO) : indicates an Application Object. The abstract reuse object model between the Web layer and the Service layer is very close to the presentation layer, and the reuse degree is not high.
• VO (View Object) : Display layer Object, usually an Object transferred by the Web to the template rendering engine layer.
• Query: Data Query object. Each layer receives Query requests from the upper layer. Note that queries with more than two parameters are encapsulated. Do not use the Map class for transmission.

Each layer basic their corresponding domain model, so it caused some people too pursuit of each layer is with your own domain model, which led to an object may appear three times 4 times even in a request, also can appear when return 3-4 times, this may be a full request – return object will appear many times. If this was the way to go in development, you’d probably stop writing anything else and just write this repetitive and useless logic for a day.

So we had to compromise:

1. Allow Service/Manager to operate the data domain model, for this level, the original work is to do business logic processing and data assembly.

2. The Domain model of the Controller/TService layer does not allow the DAO layer to be passed in, which is not in line with the division of responsibilities.

3. Similarly, do not allow DAO layer data to pass into the Controller/TService.

4. To summarize

In general, business stratification is very important for code specification, which determines whether the code can be reused in the future, whether the responsibility is clear, and the boundary is clear.

Of course, this kind of stratification actually differs from person to person, and everyone in the team has different stratification habits, so it is difficult to weigh out a standard criterion. In general, as long as the responsibilities are clear and the follow-up maintenance is easy, it is a good stratification.

Finally, if your team has better layering, or if there is something wrong with the above description, please leave a comment.

For more technical information, please follow the public account

Finally, this article is included in JGrowing, a comprehensive, excellent, community-built Java learning route. If you want to participate in the maintenance of open source projects, you can build together. Making the address is: https://github.com/javagrowing/JGrowing trouble yo give a little star.