1. Architecture layering in software
In our daily development of applications, the general process is user interface to service, service to database. The problem here is that the business logic may be scattered between the user interface and the database logic, with less cohesion and less coupling. Of course, for less important and urgent projects, this is the easier way to do it.
Note, however, that it can be very difficult to view and analyze domain code if domain-specific code is scattered among a large number of other code. Changes to the user interface can actually change the business logic, and tweaking the business rules will likely require careful scrutiny of the user interface code, database operation code, and so on, and you’ll fall into a trap if you’re not careful. That way, let alone implementing a consistent model, an implementation that most people would probably steer clear of.
So for applications with complex business logic, try not to go DIRTY AND QUICK.
So what do you do if you want to create business logic that deals with complexity? The answer is a separation of concerns. At the same time of separation, complex interactions within the system must be maintained. Thus, Layered Architecture was born.
So, you see, layered architectures were not invented by DDD, they were widespread and varied before DDD. However, most successful architectures use some variation of these four conceptual layers:
| layered | Duties and responsibilities |
|---|---|
| User interface layer | Responsible for displaying information and interpreting user instructions to the user, which could be another computer system, not necessarily the person using the user interface. |
| The application layer | Define the tasks that the software is supposed to accomplish and solve problems by objects that only express domain concepts. This layer is responsible for work that is significant to the business and a necessary channel for interaction with other system application layers. The application layer should be as simple as possible without business rules or knowledge, but only coordinate task allocation work in the domain objects of the next layer, so that they cooperate with each other. It does not reflect the state of the business situation, but it can have another state, showing the progress of a task for users or programs. |
| Domain layer (or model layer) | Responsible for expressing business concepts, business state information, and business rules, although the technical details of holding business state are implemented by the infrastructure layer, the state reflecting business state is controlled and used by this layer.The domain layer is the core of business software. |
| Infrastructure layer | Providing common technical capabilities for the layers above, messaging for the application layer, persistence mechanisms for the domain layer, drawing screen components for the user layer, etc., the infrastructure layer can also support interaction patterns between the four layers through software architecture. |
On a daily basis, some projects have no obvious division between the user interface layer and the application layer, while others may have multiple infrastructure layers. However, separating the domain layer is the key of Model-driven DESIGN.
Eric describes the importance of architectural layering in complex software as follows:
Layer complex applications. Design it separately within each layer so that it is cohesive and dependent only on its lower layers. Using standard architectural patterns, only loosely coupled with the upper, put all the code associated with the domain model in a layer, and put it to the user interface layer, application layer and infrastructure level code apart, domain objects should focus on how to express the domain model, and do not need to consider their own display and storage problem, also need not task management application, etc. This makes the model meaningful enough and structured enough to capture basic business knowledge and use it effectively.
Layered architecture is an important part of DDD. When many people think of DDD, the first thing that comes to mind is the layered architecture, which has a certain relationship with the thinking of technical personnel. However, while hierarchical architecture is not the whole story of DDD, it is still important to understand it.
The above description will be somewhat abstract, but let’s do a brief analysis of the layers below.
Ii. User Interface
The user interface layer is the top layer of the application and is responsible for presenting information to the user and interpreting user instructions. However, Eric’s situation when he came up with DDD was very different from today’s software development. At that time, there was no separation of the front and back ends, the user interface layer and other layers of code in the same project, now the front interface code has been separated.
So, since the front-end code is separated, does the server have to leave this layer alone? No, that would be too narrow.
For the user interface layer, note the following:
- Task-driven user interface: although the interface is isolated and independent, the logic still exists, and this layer can be used to respond to various requests from the front end;
- Device friendly: Be friendly to Web and mobile devices.
- User friendly: This layer is also device friendly by nature, providing different response and processing logic for the device used by the user to improve the user experience;
- Does not involve business logic processing;
If you look at the user interface layer this way, you’ll see that it takes on a bFF-like responsibility. In our existing generic code structure, it is the outermost layer of the API.
Application layer
The application layer is an important but seemingly obscure layer of layered architecture. Let’s review the previous description of the application layer:
Define the tasks that the software is supposed to accomplish and solve problems by objects that only express domain concepts. This layer is responsible for work that is significant to the business and a necessary channel for interaction with other system application layers. The application layer should be as simple as possible without business rules or knowledge, but only coordinate task allocation work in the domain objects of the next layer, so that they cooperate with each other. It does not reflect the state of the business situation, but it can have another state, showing the progress of a task for users or programs.
Important to understand the application layer are:
- Everything it does is for the user (not narrowly defined as UI, but possibly as a two-way call);
- The application layer reflects the user story, what the user needs, it needs to prepare what;
- The application layer can organize and coordinate different domain layers to achieve user goals.
- The application layer is also the protective layer of the domain layer. Do not directly expose the domain layer.
Fourth, business logic layer
The business logic layer represents the application layer + domain layer. This representation is not often seen on the typical DDD layered architecture diagram, but it is simply not shown explicitly (shown in the figure above) and does exist.
This is because, in the design of a software system, the business logic of the software system is abstractly composed of two main parts: application logic and domain logic. Application logic is an important part of the code and is strictly dependent on the user story (use case). Domain logic, on the other hand, is immutable and does not change as use cases change. Use cases can come out of the mouth, but the domain logic must be solid. For example, there can be many ways and means of appointment in test drive, but the internal domain logic of appointment must be consistent and stable.
Therefore, we can’t just talk about the domain layer without leaving the application layer, because then you will find that a lot of business rules and logic can’t be put in place and you don’t know where to write the code, the root cause is not understanding the existence and difference of the application logic domain.
5. Domain layer
The domain layer is the essence of the DDD layered architecture. It is the unchanging part of the business system, the representation of the domain model and all the design elements directly related to it, and consists of the design and implementation of the business logic. In model-driven DESIGN, software construction at the domain level reflects MODEL concepts.
This consistency is not possible if the domain logic is mixed up with other concerns in the program. Therefore, domain implementation independence is the premise of domain-driven design.
As for the details of the domain layer, I will not repeat them here, and there will be independent article analysis later. Just understand its positioning and importance for now.
6. Infrastructure layer
As mentioned above, the infrastructure layer provides common technical capabilities for the layers above, messaging for the application layer, persistence mechanisms for the domain layer, and so on. The infrastructure layer also supports interaction patterns between layers through software architecture.
There are two things to note in the infrastructure layer:
- Non-domain logic and application logic support, tool code should be separated into the infrastructure layer;
- Do not have multiple infrastructure layers in the same project. Within the same organization, try to consider that the infrastructure layer can be reused across projects.
summary
This article focuses on the origin and importance of hierarchical architecture in DDD. In practice, a specific framework is not necessary to implement a layered architecture. It can only be said that the proper application of a framework can reduce the complexity of a layered architecture and make it easier to use and fall into place without being constrained by external frameworks. Keep in mind that an architecture that isolates domain-specific code, resulting in a cohesive domain design while keeping the domain loosely coupled to the rest of the system, may be able to support domain-driven design.
If you do use a framework, it is important to consider the support and limitations of the framework on complexity and flexibility, and more importantly, the ability and willingness of the organization to accept it.
About the author
Pay attention to the public number [technology at 8:30], timely access to the update of the article. Pass on quality technical articles, record the growth stories of ordinary people, and occasionally talk about life and ideals. 8:30 am push author quality original, 20:30 PM push industry depth of good articles.
If this article was helpful to you, please like it and follow it.