preface

The application layerization and domain model described in this paper is a practice protocol (explanatory document) synthesized by me based on some thinking of business practice process and combining with the current mainstream business norms and technical framework in the industry. The protocol is not a standard, it is mainly used to guide our future project research and development, welcome your reference and discussion.

Application layer

This is the hierarchical structure recommended in chapter 6 [Engineering Structure] of Alibaba Java Development Manual (Songshan Edition), as shown below:

Please refer to the original text of the manual for hierarchical explanation. Here I only describe my own understanding.

  • The terminal display layer and the open API layer can be understood simply as the client, primarily for making HTTP or RPC requests.

  • The Web layer, also known as the Controller layer, is mainly used to validate the request parameters, call the Service layer to process the business logic and return the results.

  • The Service layer, which is used to encapsulate the implementation business logic, focuses here on the Manager layer.

The Manager layer is mainly used to encapsulate the general business logic in the Service layer and realize the reuse of business logic. Note that business logic is also one of the reusable components.

What might be common business logic? Here are a few common scenarios:

  1. The cache.

  2. Combinatorial reuse of Dao;

  3. In addition, the recurring cliches in the Service layer can be considered (but not required) to be migrated to the Manager layer;

  • The Dao layer is mainly used to encapsulate data access logic, not only limited to databases, but also data interfaces or other third-party services.

To simplify the hierarchical structure diagram:

The arrow on the left indicates the direction of data inflow: client -> Controller layer -> Service (Manager) layer -> Dao layer;

The arrow on the right indicates the direction of data outflow: Dao layer -> Service (Manager) layer -> Controller layer -> client;

The logical business meaning of the flow of data between layers (in and out) is not exactly the same as the physical data structure, and the concept of a domain model was developed to clearly define the state of the data at a certain layer.

The domain model

The domain model is essentially a POJO (Plain Old Java Object).

What is a POJO?

This is Plain.

-Penny: Old. I used to wonder why it’s Old. It was later understood that this was extended to the most primitive and initial;

Java Object: A Java Object.

Pojos are the simplest, most primitive, plain Java objects.

What are unusual Java objects?

Most technical frameworks now require Java objects to inherit specific classes or implement specific interfaces, or to be annotated in a variety of ways, and these Java objects can be considered unusual.

The domain module consists of three parts:

  • The class name indicates the service meaning.

  • Field, representing data structure;

  • Method, representing the supported operations;

Alibaba Java Development Manual (Songshan edition) also gives a reference to the domain model:

  • Data Object (DO) : This Object corresponds to the database table structure one by one and transmits Data source objects up through the DAO layer.

  • Data Transfer Object (DTO) : a Data Transfer Object that is transmitted by the Service or Manager.

  • Business Object (BO) : a Business Object that encapsulates Business logic and can be output by the Service layer.

  • Query: Data Query object. Each layer receives Query requests from the upper layer. Note that query encapsulation with more than two parameters is prohibited by using the Map class for transmission.

  • VO (View Object) : Display layer objects, usually transmitted by the Web to the template rendering engine layer.

There are a lot of different explanations on the web about what an application is and what each O is. There is no right or wrong explanation. This article describes my own understanding of the flow of data between application layers.

QO (Query Object)

Query object used by Controller layer methods to receive client request parameters.

Take the query object MyQuery as an example:


public class MyQo {

private String param1;

privateString param2; . }Copy the code

In Controller layer methods, query object creation takes two forms:

  1. The framework automatically creates MyQo objects and completes the mapping between request parameters and object fields.

@PostMapping("/post")

public String post(@RequestBody MyQo qo) {... }Copy the code
  1. Manually create MyQo objects, and complete the mapping of request parameters and object fields one by one;

@GetMapping("/get")

public String get(@RequestParam String param1, @RequestParam String param2) {

MyQo qo = newMyQo(); qo.setParam1(param1); qo.setParam2(param2); . }Copy the code

After the query object is created, it can be used as a parameter to the Service layer method:

service.doSomething(qo); .Copy the code

During this process, data flows from the client to the Controller layer.

Note: If the number of request parameters is small, such as 1 or 2, you can use the request parameters instead of creating the query object.

BO (Business Object)

Business objects, which are used for logical processing within the Service layer methods and for outputting business objects to the upper layer (the Controller layer).

  1. Service layer method internal logic processing

Taking Create in CRUD as an example, if we need to Create a business object (BO), the Service layer method can be roughly divided into three steps:

1.1 Querying the mapping between an object and a service object.


MyBo bo = mapper.map(qo);

Copy the code

The client flows the multiple fields needed to create the business object into the Controller layer in the form of request parameters; The Controller layer uses the query object QO to receive request parameters and flows the query object QO into the Service layer. The query object QO contains multiple fields needed to create business objects. The fields in the query object and the fields in the business object may not have the same name and number of fields (depending on the business scenario), so a mapping (mapper.map) is required.

Note: Mapping tools are provided by a number of open source technical frameworks and are not discussed in this article.

1.2 Mapping of business objects to data objects (DO);


MyDo do1 = mapper.map(bo);

MyDo do2 = mapper.map2(bo);

Copy the code

A data object (Do) corresponds to a table of data in the database, as detailed below. Business objects and data objects do not necessarily correspond one to one; usually one business object corresponds to multiple data objects.

Take the resume object as an example. It usually includes:

  • Education experience

  • Work experience

  • Project experience

The data from these experiences is stored separately in different data tables, each of which corresponds to a data object. That is, the resume object corresponds to three or more data objects, and therefore also requires mapping (mapper.map and mapper.map2 stand for mapping a business object to different data objects, respectively).

1.3 Call Dao layer methods to save data objects;


dao1.doSomething(do1);

dao2.doSomething(do2);

Copy the code

Dao layer methods persist data objects to the corresponding data tables and then return the saved results to the upper layer.

  1. The Service layer methods output business objects to the upper layer (the Controller layer)

Taking Read in CRUD as an example, if we need to Read a business object (BO), the Service layer method can be roughly divided into three steps:

2.1 Call Dao layer methods to obtain data objects;


MyDo do1 = dao1.getSomething1(qo);

MyDo do2 = dao2.getSomething2(qo);

Copy the code

Dao layer methods read several data objects corresponding to business objects using query objects (or, as needed, mapping query objects to those suitable for Dao layer methods) as parameters.

2.1 Mapping of data objects to business objects;


MyBo bo = mapper.map(do1, do2);

return bo;

Copy the code

Map several data objects to a single business object, and then return the business object to the upper layer.

In this process, data flows from the Controller layer to the Service layer, and then from the Service layer to the Dao layer. The data then flows out in reverse.

DO (Data Object)

Data object, each data object corresponds to a data table in the database, which is used for Dao layer methods to store data objects and output data objects to the upper layer (Service layer).

  1. Dao layer methods save data objects;

int saveMyDo(Mydo do);

Copy the code
  1. Dao layer methods output data objects to the upper layer (Service layer);

Mydo getMyDo(int id);

Copy the code

The saving and reading of data objects at the Dao layer are usually done with the help of technical frameworks, which have different implementation details and will not be discussed in this article.

VO (View Object)

Display object used by Controller layer methods to return client request results. The data from the Service layer can be displayed in the following situations:

  1. The business object

The Service layer outputs business objects, typically seen in Read scenarios, where business objects need to be mapped to display objects:


MyVo vo = mapper.map(bo);

return vo;

Copy the code

The client does not need all the fields of the business object, or the fields of the business object need to be combined/transformed to meet the needs of the client, so mapping is required; Once the mapping is complete, it can be returned to the client.

  1. Operating results

The result of the operation may be ID, success or failure, 0 or 1, etc. As seen in Create/Update/Delete scenarios, mapping is not required and specific results are returned to the client by protocol (client-server convention).

  1. Nothing at all

The return type of the Service layer method is void, which actually returns a result. For example, if there is an exception, the specific result can be returned to the client according to the protocol.

Note: A similar situation occurs when Dao layer methods flow out to the Service layer, which will not be described here.

In this process, data flows from the Service layer to the Controller layer; The data then flows out to the client.

Data Transfer Object (DTO)

Data transfer object, I understand that QO and VO used for data interaction between client and server are very typical DTOS, can refer to this article, no further details.

Another interpretation, which I agree with, is that data transfer objects can be used not only for end-to-end data interaction, but also for layer to layer data interaction. Taking business objects as an example, if we only want to query or update some of the fields of a business object, do we need to create a special model object for those business objects that contain only some of the fields, such as dtos? My view is no, reuse business objects whenever possible (note that you don’t have to). So, how do you use business objects to express partial field business objects?

Fields of business objects require all object types, not primitive types. Using int as an example, use Integer instead to define fields:


public class MyBo {

private Integer param1;

private Double param2;

private String param3;

privateObject param4; . }Copy the code

Since the business object field types are all object types, we can perform conditional operations on the result of the test by checking whether the field value is null:

  • Query some fields of the business object. Those fields that do not need to be read can be set to NULL, and the null fields are ignored when the data is returned.

  • Update some fields of the business object. Those fields that do not need to be updated can be set to NULL, and these fields with null values are ignored during data update.

This requirement is recommended for all domain model objects.

The core goal is to keep the system design simple, not to introduce specific objects to solve specific problems, and to reuse existing objects as much as possible. There is some complexity involved in the implementation process, but I think it is worth it.

summary

[Protocol] Generally speaking, it is a set of rules agreed by all (organizations/teams) and followed together. It is not a standard rule in the general sense, and different rules you can use are different, so pay attention to that.

In addition, both the hierarchical structure and the domain model are designed to serve the business. The design is ultimately determined by the business effect, and what is appropriate is good.