Software Architecture-service layer

In the ddd design, we often mention the service layer. What is the service layer? What is the responsibility? What are the benefits ?.

First, let's look at the simple Hierarchy Diagram. Note: here we didn't consider other redundant domain logical data layer storage, or UOW)

650) this. width = 650; "style =" border-top-width: 0px; border-bottom-width: 0px; border-left-width: 0px; border-right -: "title =" image "border =" 0 "alt =" image "width =" 762 "height =" 380 "src =" http://www.bkjia.com/uploads/allimg/131228/1IZS953-0.png "/>

In my understanding, the service layer is the application boundary between the application business layer and the performance layer. The boundary may be a thin layer of class design or a distributed service network hop. It is a term unrelated to technology. Directly called by the presentation layer, contract, execute the command to modify the status CUD) or query the returned dto data migration object) cms, command-query separation ). It is clear to the business logic layer interface that the organizational business logic microservice forms a macro service and adapts to the presentation layer.

Here we will talk about macro services and microservices. Macro services have some coarse-grained services. A user's usecase operation, such as an e-commerce order, CreateOrder is a macro service, rather than fine-grained goods inventory check and order legality. The corresponding microservice is sometimes called an Application Service). It is represented by the logic details of the problem domain, such as the fine-grained services such as inventory check and validity check. Macro Service is composed of one or more microservices. Sometimes our usecase logic is very simple. The service layer is composed of only a single microservice, and realization is a few simple microservice calls.

Responsibilities of the service layer:

1: in-area software development, whether it is structured programming sp) or object-oriented programming oop) We have been strongly increasing cohesion, low coupling, separation of concerns soc ). The service layer is between the application and business layers, and the application boundary makes two direct decoupling. The third object destroys the direct dependency between the two objects and converts the do object to be adapted to the domain object) and try to object vo.

2: The service layer hides the details of the business logic layer. It needs to organize business microservices internally to provide more macro and performance-oriented service logic, and expose and package services using contract interfaces. All the interactions of the system go from the presentation layer.

Currently, the popular SOA architecture provides a distributed service architecture that focuses on services and improves the reuse of services and business logic. However, the services mentioned here are not specific technologies such as wcf or webservice, at the same time, a service may be composed of some coarse-grained classes of certain columns in a contract. However, the use of SOA or MTS to establish services gives our services more and more additional advantages, such as security, transactions, logs, and scalability.

Advantages of the service layer: As described above, the service layer provides the same interface contract and entry for the performance layer. Let our business layer focus on and implement the logic of the problem field and the actual needs of the problem field. Micro-services should be organized to avoid too many fine-grained service calls flooding into our project performance Layer and problem areas, with too much interaction. If we adopt soa and other service fields, our applications can easily cross application boundaries and network hops. However, you need to pay a little performance price.

Data Migration object dto) is an object that carries data through the application boundary and reduces the number of interactions between data. We often use it as a value object, which is just a set of simple get and set attributes, no action is performed. It is only the data carrier. In Domain Design, dto is a very important model. Not all of our domain objects can easily reach the presentation layer. Only the presentation layer and domain layer are deployed in the same physical location. If you need to go through the network hops or process boundaries, because domain objects make the core of our business have many natural world relationships, dependencies, and even circular dependencies such as e-commerce users and orders, A set of user orders, and each order points to a specific user, we must replace this cycle dependency to make it serializable and pass through the hop. Second, our domain objects are often a bunch of rich objects in the field, and there is a large amount of data. In many cases, we do not need all the data information in our scenarios. With the existence of dto, we can solve these problems well. Yes, our project has become simplekeep it simple and Stupid. KISS principle ).

But at the same time, the existence of dto will bring us some extra complexity. We must have a layer of do-to-dto ing adaptation layer.

Theoretically perfect design we need to define a dto for each application, but in a complicated system we may have many domain objects, adding 500 do, each do usually has multiple dto, which adds a large set and mapping logic, and poses great maintenance challenges. In the software field, there is a saying that the number of bugs increases as the amount of Code increases and the number of test points also increases. Unless we have to cross the application network hop border, I think we can also use simple do directly. Based on world projects, the situation is determined by our architects.