Shulou(Shulou.com)06/03 Report--

We often mention the service layer in ddd design. What is the service layer? What is the duty? What are the benefits?

Let's take a look at the simple hierarchical diagram (note: other redundant domain logical data layer storage or UOW details are not considered here)

My understanding is that the service layer is the application boundary between my application business layer and presentation layer, which may be a thin layer of class design or a distributed service network hop. It is a term that has nothing to do with technology. Directly invoked by the presentation layer, contract, execute commands (modify status (CUD)) or query returns dto (data migration objects) (cms, command-query separation). He is very clear about the interface of the business logic layer, organizing the business logic micro-services to form macro services and adapting to the presentation layer.

Here we talk about macro services and micro services, which are made up of a series of coarse-grained services. A user's operation usecase, such as e-commerce to issue an order, CreateOrder is a macro service, rather than a fine-grained inventory check in the order, order legitimacy and so on. The corresponding micro-services (sometimes called application services) are represented by the logical details of the problem domain, such as the fine-grained services such as inventory checking and legitimacy checking above. Macro service is composed of one or more micro-services. Sometimes our usecase logic is very simple. The service layer is only composed of a single micro-service, which is transformed into a few simple micro-service calls.

Responsibilities of the service layer:

1: in-person software development, whether structured programming (sp) or object-oriented programming (oop), we have always emphasized high cohesion and low coupling, separation of concerns (soc). The service layer lies between the application layer and the business layer, the application boundary makes two direct decoupling, uses the third object to break the direct dependency of the two objects, and transforms the difference between the adaptive domain object (do) and the attempt object (vo).

2: the service layer hides the details of the business logic layer, and it needs to organize business micro-services, provide more macro, presentation-oriented service logic, expose and package using contract interfaces. All interactions in the system are entered from the presentation layer.

At present, SOA architecture is popular, which provides a distributed service architecture, which focuses on services and improves the reuse of services and business logic, but the services mentioned here are not specific technologies wcf or webservice. At the same time, services may be composed of a series of coarse-grained organizations that specify contracts at the same time. But building services using SOA or MTS will give our services more additional advantages, such as security, things, logging, and scalability.

The advantages of the service layer: the same interface contract and entrance provided by the service layer for the presentation layer as mentioned above. So that our business layer can pay attention to and implement the logic of the problem domain and the actual needs of the problem domain. Organizational microservices avoid too many fine-grained service invocations flooding our project presentation layer and problem areas with too much interaction. If we adopt service areas such as soa, we can easily cross application boundaries and network hops. But there is a little performance price to pay.

Data Migration object (dto) is an object that carries data across the boundary of the application, reducing the number of data interactions. Often, we regard it as a value object, which is only composed of a set of simple get,set attributes. There is no behavioral operation, only the carrier of data. Dto is a very important pattern in domain design. Not all of our domain objects can easily reach the presentation layer, only the presentation layer and the domain layer are deployed in the same physical location. If we need to cross network hops or process boundaries, because domain objects make the core of our business have a lot of natural world relationships, dependencies, and maybe even circular dependencies such as e-commerce users and orders, a collection of user orders, and each order points to a specific user, we have to break this circular dependency in order to make it serialized through the hop. Secondly, our domain objects are often a bunch of domain-rich objects, there is a lot of data, many times our scene does not need all the data information. With the existence of dto can solve these problems very well, yes, our project has become simple (keep it simple,Stupid). KISS principle).

But at the same time, the existence of dto will bring us some additional complexity, we must have a do-to-dto mapping adaptation layer.

Theoretically perfect design we need to define a dto for each application, but in a complex system we may have a lot of domain objects, adding 500 do, each do will generally have multiple dto, which will add a huge collection and mapping logic, and there will be no small challenges for maintenance. There is a sentence in the software field that the number of bug increases with the amount of code, and the number of test points needs to increase with the increase of code. Unless we have to cross the boundaries of application network hops, I think we can also have some direct use of simple do. According to the World Project, the situation is decided by our architect.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.