1. What is Domain Driven?
Domain-Driven Design Domain-Driven Design, referred to as DDD. Software does not have such high requirements for the industry. It itself helps other industries develop better and empowers other industries. There are software in various industries, but their business scenarios are different, so a lot of business sorting is required. It may require a special person to sort out, that is, a product manager.
Our development needs may be from operation to product to architecture, and finally to our developers. After passing through layers, the initial operation plan may be completely different from the plan that falls to the developers. What is finally made may be different from what the operation wants.
In the early stage, our domain model may be database design , directly build tables according to the business, and then perform object mapping according to the situation of the table. Our design process is from building tables to deriving objects. In this case, if the business changes, the degree of coupling will increase, and it will not meet the faster and faster development pace. In the original waterfall development, it was possible, but now the Internet has entered a fast-paced, agile development, and the entire project cycle may be in the experimental stage, and the requirements change at any time.
So we have to use more abstract things to do domain modeling. Domain-driven design is divided into three stages: conceptual design, logical design, and physical design. Conceptual design is concept association diagram, concept class, domain class diagram, filling attributes, etc. Logical design is mainly business collection and business model. Physical design, physical selection, may overturn the redefinition of the above theory, data storage issues, and so on.
2. Domain-driven and microservices
In 2004, Eric Evans published "Domain-Driven Design" and identified the core ideas of Domain-Driven Design:
That is, the domain model is defined through the domain-driven design method, so as to determine the business and application boundaries, and ensure the consistency between the business model and the code model.
But after this concept was proposed, DDD was very popular, but there has been no implementation plan. Until the official release of springcloudd1.0.0 in 2015, the first Release version of springcloud netflix appeared in 2016, and it has been out of control ever since.
How to disassemble the "micro" of microservices, how small is one?
At this time, domain-driven design plays a role. Domain-driven design is used to divide the domain model, and micro-services are divided from the business perspective according to the domain boundary. Many companies now regard domain-driven design as the guiding ideology of microservices.
In what way does the domain drive define boundaries?
1. Strategic design: from a business perspective, establish a business model and divide business boundaries
2. Tactical design: implement technology according to the business model, complete software development and implementation
3. Common concepts of DDD
1. Field
The essence of a domain can be understood as a problem domain. As long as it is the same domain, the problem domain is the same.
For example: the problems in the field of traditional e-commerce are nothing more than orders, commodities, logistics, payment, inventory, etc., and absolutely will not design related issues such as travel, politics and law. In addition to traditional e-commerce attributes, social e-commerce will also have additional Social networking and communication related functions.
2, subregion
Subdomain: You can understand it as a more subdivided domain, and you can even subdivide the subdomain into more subdomains.
For example: Is the e-commerce platform regarded as a field? Orders, warehousing, and logistics can all be subdomains, and warehousing can also be divided into local storage, third-party warehouses, and remote warehouses. These can be thought of as subdomains.
Core subdomain: The core of the entire business system, all businesses must be developed around the core subdomain.
General subdomain: subdomain, authentication and authorization modules that can be used in the entire field.
Support sub-domain: The support domain actually does not include core competitiveness functions and general functions, but it is a necessary support.
3. Common language
In a project, technical experts, architects, back-end, front-end, and testing will all participate, but during the conversation, as the back-end, you may feel that the product can’t get your point at all, and the product also thinks that you can’t get it. There will be a problem of chicken talking with duck. At this time, there must be a unified common language to come out with unified standards, a language that can express business logic correctly, simply and clearly, and allow everyone in the project to reach a consensus.
4, limit upper and lower sentences
It is used to encapsulate common language and domain objects, provide context, and ensure that some terms in the domain, business-related objects and other common languages have an exact meaning without ambiguity. This boundary defines the applicability of the model.
4. Domain Model
Also called a business object model, it describes the reference relationship between business objects.
Business objects: 3 types
- Business role: cashier, responsibilities: calculate commodity prices, collect money, give change, return and exchange
- Business entities: deliverable artifacts required to interact with business roles, commodities in e-commerce projects, and invoices.
- Business Use Case: How to execute workflow between business roles and business entities
Blood loss model: The object only contains attributes and get and set methods. The advantage is simplicity. The disadvantage is that all business logic is included in the service, which is all business code, which is difficult to maintain and cannot cope with frequently changing requirements.
Anemia model: A persistence layer is added on the basis of the blood loss model. It is not necessary to access the database at the business layer, and directly operate the persistence into an indirect operation database, and then also include some inherent behaviors (People's walking, eating, sleeping), non - intrinsic Behaviors (people's: typing codes, playing games, doing algorithm problems, etc., these are not for everyone) are written in the service. Advantages: clear hierarchical structure, one-way dependence of each level, for a small number of business applications, it is very natural to use and fast to develop. Disadvantages: unable to cope with very complex scenes. (most used)
Hyperemia model: It is more in line with the object-oriented principle, including all the inherent and non-intrinsic behaviors in the model. Our business layer will only do the role of integration and encapsulation. The business logic layer is very thin, which is in line with our single responsibility principle. Disadvantages: The level of developers must be very high, and the model contains a large number of operations. When you go to instantiate, it will increase a lot of unnecessary consumption.
Swelling blood model: the service layer is canceled, and all business logic integration is placed in the domain model, which simplifies the layered architecture, which is also in line with the object-oriented design principle, cancels the business logic layer, and directly encapsulates transactions and domain objects Authorization may authorize a lot of logic that does not belong to objects in this domain, thus affecting the instability of the model. Code stability and maintenance stability.
Five, DDD layered architecture design
Traditional three-tier architecture
In order to better get closer to business implementation, domain-driven also has its own architecture design methodology. The traditional three-tier model focuses on the database, so the database will be used as the starting point for analysis. The domain-driven design focuses on the domain model, so it will be used as the basis for analysis.
The user interface layer displays information to the user, and the external model, which is not a model of the domain layer, will be converted into a model of the application layer by an assembler. There is an arrow that can directly access the domain layer
The application layer specifies the tasks to be completed in the domain, and performs business logic with the model that has nothing to do with entities.
Domain layer, expressing business concepts, status of business information, business rules
The infrastructure layer, which provides the interaction layer for the upper layers