System layering-> simple L3-> DDD hierarchy

In the process of developing applications for enterprises, it is very important to break down a large and complex system. System hierarchy is an important way to break down the system.

-> NO Layer

At the beginning of myProgramDuring a career, the first system we do is that there is no concept of hierarchy. When the second item is system, there is a simple layering concept, but it is not very clear. There are both simple layer-3 layers, as well as reading data from the database, and directly binding the data table (datatable) toCode.

-> Simple Layer 3

It is not until after work that we refer to the first molding system of petshop after work, but we will find many unreasonable places in actual use. For example, the stored model is a typical blood loss model (as defined by Fowler ), the purpose of the system is to temporarily store the data read from the database or written into the database. The so-called business logic layer (BLL) has often become a data transfer station for the Dal layer (which I learned in my business system ). Among the logic that only adds, deletes, modifies, and queries, BLL is a simple Dal transit. These are all problems. There are also some logics, which should belong to a certain model logically, but in this layer, they need to be placed in BLL.

When I use the simple layer-3 architecture, I feel that the database is the core of the system. Basically, when the business needs are almost the same, I began to create databases and tables. Based on the created table, write the model for the table (sometimes the code generator that looks bad now will be used). The model basically only has attributes, it is the storage unit of data in the database in the memory.

Where is the real logic of the system reflected? Bll? However, some logic does belong to a model. The bll layer is hard to take these logics. In the future system design, I want to migrate some code in BLL to the model. Later, I accidentally saw the domain-driven design idea and found that some people had already provided a good solution to these problems. The anemia model (domain model) was formed ).

-> DDD hierarchy

We have discussed how to migrate some business logic from The bll layer to the model, which leads to the DDD mentioned by Evans and Fowler. This is also the layered structure I use when developing business systems at work. The Architecture Design in the business system is mostly based on the method in the enterprise application architecture model of DDD hierarchy and Fowler. It's just that many things are not fully understood, and there are also many problems in use. You also need to use and understand them.

Personally, the emergence of domain-driven design (DDD) has changed my understanding of software development and the work of software developers. In fact, many people and many books have said the above, and I am glad that I have been very familiar with this idea for a long time. Take the business field as the core and use the objects in the business field to communicate with users, so as to provide users with software that can improve their work efficiency. Most of the vocabulary used in the user professional field during communication with users should be defined in the system. Only in this way can the system be consistent with the user's business. When the user's business logic changes, our system can be easily modified.

The emergence of a domain-driven design naturally corresponds to a system layering solution. Performance layer-> application service layer-> domain model layer-> infrastructure layer. The domain model is the core layer of this layer and the focus of our attention when designing the system, this layered scheme is the default DDD layered scheme provided by Evans and Fowler.

The presentation layer is similar to the presentation layer of the simple layer. It displays the response information to the user, accepts the user input, and calls the lower layer to respond.

The application service layer coordinates the application logic layer and infrastructure layer to complete a specific task. It does not save the various statuses of the domain service, but only saves the various progress statuses of the task. However, in actual development, especially when the business flow is relatively simple, I rarely use the application service layer. Generally, a Dal can solve the business (add users ). This layer seems to be a bit similar to the BLL of simple three-layer summary, but after some logic is removed, this layer may become simpler.

The domain model layer mainly defines the terms that appear in the user's business and the actions corresponding to these terms.

The infrastructure layer is mainly responsible for the implementation of specific technologies, physical configuration, database, and interaction with external systems.

Dependencies between different layers are as follows:

Presentation Layer: dependent on the other three layers.

Application logic layer: dependent on the domain model layer and infrastructure layer.

Domain logic layer: independent of any layer.

Infrastructure layer: Dependent domain model layer.

 

In addition, there is a more detailed breakdown of this layer, and some also extract data access interfaces. I have also made a lot of reference, and it is too complicated. Basically, a slight extension on the basis of the layer-4 above can meet the daily development requirements of our company.

When using a hierarchical system, we should consider the level of the company's employees and the size of the project, and our department will basically adopt this hierarchical model. The main logic is separated and the focus is not introduced too much complexity. Is there a better way of layering? Certainly, there are many, and I have been researching. However, this layering method is currently the most suitable for our use.

Furthermore, this layering method is suitable for most business application systems. However, this may no longer apply to special or platform systems.