During the construction of the internal website of the enterprise, the backend of the website initially adopts the traditional table mode development method. This method can easily cause the core business logic and business rules of the site to be distributed in various layers and objects of the architecture, which makes the reusability of the system business logic not high. In order to solve this problem, the author introduced the development method of domain-driven design in the later development process, modeled the business logic of the system independently, fully reused, and created an easy-to-extend development framework based on these models, which improved the entire team. The efficiency of developing business logic, the final website was launched as scheduled, and it has been running stably so far.
Table of contents
1 Three modes of software development
1.3 Domain-Driven Design Patterns
Digitization is an indispensable link in the system construction of every IT enterprise, and the internal website of an enterprise is often an important symbol and part of digitization. The internal site construction project of the enterprise was born in this scenario, mainly to provide the required functions of managing various process systems for the smooth development of the daily work of the R&D department.
At the beginning of the project, the author chose the common table mode to develop the backend of the website in the research and development method, and chose the traditional multi-layer architecture to organize the code in the architecture. This kind of technology selection and matching is often used to develop small projects with relatively simple business logic. The entire development process focuses on specific database design and process-oriented development, which is simple and easy for team members to learn.
However, when the functions of the website gradually increase, the complexity of the system rises rapidly. Using this combination makes the business logic of the system unfocused. In the end, they are scattered in various layers and objects of the architecture. The reuse of business logic Sex is bad.
In order to solve this problem, the author introduces the development method of domain-driven design. This development method focuses on changing business logic and manages them as the core model of system development, so that the business logic of the system can be fully reused, and the development efficiency of the entire team has been significantly improved.
1 Three modes of software development
In software development, according to the different R&D processes, the development process is generally divided into three modes: transaction script, table mode and domain-driven design.
1.1 Transaction script
1) Mode introduction
Today, although the mainstream programming languages are all object-oriented languages, many teams adopt a process-oriented development mode. The objects used in the code have no practical meaning, and are purely the carrier of the code script.
Transaction script (Transaction Script) is such a simple development model, which completely adopts a process-oriented approach, and directly translates the operations performed by users on the presentation layer into code scripts (such as SQL statements, batch statements, etc.) The mode of execution.
2) Implementation method
Usually, implementing the transaction script pattern will not carry out object design, nor will it layer the involved components, and all operations from the presentation layer to the bottom layer will be put together.
A typical example is a page displaying a list of books. During development, a list control is usually placed on the interface, and then the control is directly bound to the SQL statement for obtaining books from the database for data filling. The same is true when adding and modifying books, directly providing SQL statements to operate the database.
Of course, in order to make the structure of the whole program clearer, when using the transaction script mode, many teams will also perform simple layering. This is the origin of the basic multi-layer architecture, that is, the application is divided into three floors.
Under the layered architecture, the application divides and organizes the entire business process in different layers. The components that directly interact with the user are placed in the presentation layer. The logic layer and the business logic layer call the scripts of the underlying data access layer to operate data sources such as databases and file systems to complete the business logic.
In this process, the focus of system design is still process-oriented, and each layer and object is just the carrier of the process, and there is not much difference in the specific name.
3) Application scenario
transaction script is a commonly used development mode. For those simple scenarios with simple interaction logic and business model that will hardly change and develop, such as common "addition, deletion, modification and query" applications, the efficiency of the entire development process will be very high. high.
1.2 Table schema
1) Model introduction
In the research and development process, the database, as the most important data carrier, will almost inevitably appear in the development process of any project. In transaction scripts, interaction with the database is basically done by using SQL statements directly in the code.
In common programming languages, SQL statements exist as strings, which brings about a problem. Since the content of strings does not participate in compilation, if there are syntax problems in SQL statements, it can only be generated when the application is running. Errors will be found, not at compile time, which sometimes poses a potential release risk.
In order to optimize the experience of operating the database and improve the efficiency of code writing, in the data access layer, after continuous attempts and efforts of engineers, a new data interaction method has emerged, which is to operate the database through entity objects in the programming language data in .
2) Implementation methods
Take the table mode as an example. In practice, they are based on transaction scripts and turn script operations into object operations. This process is generally completed through a specific framework, which is generally called "Object Relational Mapping (ORM)". The ORM framework maps the structure in the relational database to the entity object in the language. When the method of the entity is called, the ORM framework will translate the object operation into an SQL statement, and then act on the database, as shown in Figure 2.
3) Application scenarios
The table mode optimizes the experience of database access, but does not involve any business logic processing, so the table mode, like transaction scripts, is very suitable for those scenarios with simple business logic, but not for more complex application scenarios. suitable.
1.3 Domain-Driven Design Patterns
1) Modes introduce
two development modes, transaction script and table mode, which mainly adopt the process-oriented programming method, and in the process of application development, the requirements analysis and system design are mostly separated, so that the early work of application development Separated, this also leads to the incomplete match between the results of the requirements analysis and the code of the system design, so that after the software is launched, the customer finds that many functions are not what they want. Different from these two models, Domain Driven Design (hereinafter referred to as DDD) development model is a pure object-oriented design process. It takes the business domain as the core, analyzes the problems in the domain, and designs and establishes the corresponding " domain model (object)" to effectively solve the core problems in the domain.
2) Implementation method
DDD is a design idea. In order to achieve the purpose of focusing on business logic and building a domain model, the specific implementation is generally divided into two stages: strategic design and tactical design.
The main work in the strategy design phase is to identify the application domain, subdivide the domain into sub-domains, design a bounded context for each sub-domain, and obtain a unified language for describing the business through full discussions with business experts during this process. The work of the tactical design phase is to design the domain model objects in the domain layer according to the bounded context and unified language, including entities, value objects, domain events, storage, aggregation and domain services, etc. (for specific concepts and details, please refer to the literature).
There are also many forms of DDD implementation. The practice of this website adopts the classic DDD layered architecture. The overall architecture diagram is shown in Figure 3.
The presentation layer is the same as the previous architecture, mainly the interface elements that interact with the user.
The application service layer is a thin layer, which mainly converts user input into the data model required by the system and converts the data model generated by the system into the object model required by the presentation layer. It should be noted that the application service layer mainly completes the conversion and Handover work, call the infrastructure to complete some work such as persistence, and must not implement any business logic.
Domain layer is the core layer of the whole system, which contains all domain models. These domain models carry and implement all business logic and business rules. All other layers depend on the domain layer, but the domain layer does not depend on any other layers. Some auxiliary functions completed by the infrastructure layer, such as some third-party class libraries, specific persistence implementations such as ORM, etc.
3) Application Scenarios
The DDD development model is especially suitable for those scenarios with complex business scenarios, frequent changes in business logic, and relatively high system complexity, typically such as the construction of middle-end systems and the development of micro-services.