Want to know what is domain driven design, did not expect a lot of novel nouns surging out, check the data to check the hands of soft, as if poking a hornet’s nest.
What is Domain-driven design
Advantages and disadvantages of domain-driven design
Three, domain driven application scenarios
Above three questions, can only be listed questions, and no answer, into the question three. Because I’ve searched many articles, I can’t figure out what this so-called domain driver is, what its benefits are, and in what scenarios. All the articles said a lot, including the one with the word “analysis” in the title, but I couldn’t read any of them and couldn’t understand them.
The truth may be that domain design is bullshit. If you can’t explain something, either the author doesn’t really understand it, or it doesn’t work. Just like the highest level of jiuyin Zhenjing, in fact, the author’s own imagination, has not been tested in practice. I suspect the same is true for domain design. I don’t see any projects that use domain to drive design architecture. Here only do some records, gu listen to it, doubt.
Domain-driven Design (DDD), as the name implies, is the Domain, that is, business, to lead the Design of information systems. Information system is used to meet the needs of business, and in the usual development process, no matter what business, the basic development routine, the system adopts the architecture, are the same, such as hierarchical structure, the system is divided into UI layer, logic layer, service layer, data persistence layer and so on. This sounds like a bit of a tailspin. Domain-driven design works in the opposite direction, aiming to set rules by adapting technology to the business, rather than the business adapting technology.
Specifically, domain-driven design seems to be about choosing the right architecture for the business (it is said that there is an agile development method called the Crystal method, which is characterized by different development methods depending on the type of project). For the information system in the same field, we should do everything possible to abstract a domain layer, which is the core and common east of this kind of business. This layer of east east, for this kind of business, is relatively stable, little change, abstract out, no matter what technology you use to achieve, how to optimize, will not affect this layer. In the hierarchical architecture we commonly use, the upper layer depends on the lower layer, and the things containing business are often in the very lower level, which contains a lot of calls, implementation, so the program reconstruction, optimization, often bear the brunt. In domain-driven design, hexagonal architecture is adopted instead of hierarchical architecture. The domain layer is at the core, and the influence of the outer layer is decoupled through dependency injection.
Software systems never come out of thin air, but solve specific problems in the form of software. When we face complex problems in the real world, how to land in the form of software? Domain-driven design is a methodology that guides us to break down complex problems, break down the relationships between subsystems and how they work, and help us solve the problems encountered in the implementation of large complex systems.
Evic Evans (the originator of domain-driven design) divides the design of software systems into two parts: strategic design and tactical design. At the level of strategic design, important concepts such as domain, subdomain and bounded context are put forward. At the tactical design level, important concepts such as entity, value object, domain service, domain event, aggregation, factory and resource base are proposed. As shown in Figure 1:
FIG. 1 Strategic design and tactical design
The strategic design section instructs us how to break down a complex system, while the tactical section instructs us how to break down individual subsystems and what principles to follow in the process.
4. Related nouns
1. Anemia and congestion Model [Blood loss Model] The model only contains data definition and getter/setter methods, and the business logic and application logic are placed in the service layer. This class is called a POJO in Java. NET is called POCO.
Anaemia model The anaemia model contains some business logic, but not the business logic that depends on the persistence layer. This part of the business logic that depends on the persistence layer will be placed in the service layer. As you can see, domain objects in the anemia model are independent of the persistence layer.
【 Congestion model 】 The congestion model contains all the business logic, including the business logic that depends on the persistence layer.
【 Bloated blood Model 】 The bloated blood model is to put other application logic (such as authorization, transaction, etc.) that is not related to business logic into the domain model. The sensory-bloating model is a different kind of bleeding model, because the service layer disappears, the domain layer does the service layer’s job, and nothing changes.
In the domain – driven design, congestion model is used.
2. Hexagonal architecture
Generally, we use a hierarchical architecture, as shown in the following figure. However, because the business logic is responsible for implementation, interacts with the data persistence layer at the lower level, and is dependent on the service layer (or application layer) above, when the service layer is adjusted or optimized, the business logic layer may also be changed. According to the reason, the business logic layer is only responsible for the business, now caused by other factors change, the city fire, disaster, not reasonable. In order to separate the business from the implementation, dependency inversion can be used to refactor.
The idea is that our architecture is no longer layered (down from the top), but abstracts the business logic out of a domain layer, putting all the details into the application layer and infrastructure stack, with the domain layer at the center. The method of application layer and base layer is called through interface, dependency inversion, and object injection is implemented at runtime.
The more abstract the domain layer is, the more stable it can reduce the impact of outer layer changes on the domain layer. In fact, this is the core idea of domain-driven design.
【 Suitable scenarios 】 Reading/writing large scenarios with low requirements for real-time query scenarios internal state changes will trigger the synchronization of various data, such as course completion, course release and so on… External implementations are replaceable, such as MQ, which can be replaced at will
[Not suitable for scenario] : Simple CRUD business, no heavy business logic, not suitable for so complex, because there is no need to extract the domain layer
3, GRASP (General Responsibility Assignment Software Patterns)
When it comes to patterns, the most famous is the GOF design pattern. According to my understanding, THE GRASP here is the modeling mode in the stage of system analysis, and GOF is the design mode in the stage of system design and development.
GRASP can help us understand the design of basic objects and improve the awareness of object oriented design (OOD). The nine patterns of GRASP attempt to solve only one problem: how to model, how to divide and design objects, how many objects a system should have, what functions each object should include and what functions it should not include, and what relationships should be established between objects. The generic responsibility assignment software pattern, as the name suggests, is that what an object should do is determined by its responsibility, that is, responsibility drives object design.
Creator Information Expert Low coupling Controller High Cohesion Polymorphism Polymorphism Pure fiction There is an Indirection of Fabrication that prevents Protected Variations.
In the design stage, in addition to the design mode, there are design SOLID principles, we are familiar with. They have similarities to GRASP above.
The Principle of “Single Responsibility diction” in diction with “Open Closed Principle” and “Liskov Substitution” Law of Demeter Interface Segregation Principle Dependence Inversion Principle
4. CQRS (Command Query Responsibility Segregation) CQRS (Command Query Responsibility Segregation) This means that queries are separated from commands (add, delete, modify), each using a different model.
In general, we use the same model for database operations, CRUDS. CQRS has changed this by splitting the model into Command and display parts, called Command and Query respectively. Breaking the model down means you can do both with different logical processes and different hardware. An example on the WEB where a user views a page using a query model; If the data is changed, the change is parsed into several command models to perform the operation, notifying the status update when the operation is complete.
The benefits are read and write separation at the operational level, improving pertinence and reducing complexity.
The Separation of concerns (SOC) is a principle for dealing with complexity. Because intermingling of concerns leads to a significant increase in complexity, it is a principle and approach to deal with complexity to separate and treat different concerns separately.
Separation of concerns is a system thinking method widely used to solve complex problems in daily life and production. The general idea is to decompose complex problems reasonably first, then carefully study different aspects of the problem (concerns), and finally synthesize the results of all aspects to synthesize the overall solution.
Separation of concerns is also a methodological principle established in the long practice of computer science and software engineering. Modularity is one of them. It is also the core concept of object-oriented programming.
The advantages and challenges of Domain-driven Design and domain-driven design for anemia, blood loss, and congestion models Differences between hexagonal and hierarchical PATTERNS The GRASP pattern Outlines those patterns in DDD – CQRS