preface
When it comes to domain-driven development DDD, it is inseparable from object-oriented and process-oriented. Object-oriented is essentially object and behavior binding, while process-oriented is a kind of instruction, where each process processes a single request from the presentation layer. Today, the trainer said something about domain-driven development, which is recorded here to share with you.
Why do domain-driven development
Reusable, maintainable, extensible, modular, extensible, and easy to maintain, and designed to reflect the business model. Improved reusability and testability of business domain objects. Business people and designers are involved. Not people-oriented, more objective reflect business value. The domain model has its own attributes and behavior states, and maps to business objects in the real world. It has a clear division of responsibilities, and solves practical industry-based applications and rules through aggregation, reference and other relations between domain object elements. Suitable design models can be used for detailed design, and designers are required to have good abstraction ability
Transaction script
Before we talk about the domain model, a corresponding concept is transaction scripting. At the heart of transactional scripting are procedures, each of which processes a single request from the presentation layer. Transaction scripting is more procedural, difficult for machines to execute, difficult to maintain manually, and object-oriented (a mapping of the real world) is easier to understand.
Concrete manifestation: the system around the database to deal with, things script (controller, service is light, DAO is heavy)
What the domain object looks like
A typical domain model is shown in the following figure:
The following takes a transfer service as an example to compare the characteristics of the two models:
The first is the transaction script, whose model is shown below:
Then there’s the way the domain model works
There is the shadow of the strategy pattern, the expansion is strong
But it’s more complicated, it involves states
features
Business mapping of domain objects to the real world
Clear delineation of responsibilities
High reusability
Easy to understand
Complete business object description
Usage scenarios
Software development for complex business logic
High requirements for designers and developers
Not suitable for simple CRUD business
The software has good maintainability and expansibility
Several kinds of models
Bleed model: a version of development where logic is included in the service and no logic in the model
Anaemic model: independent of persistence, add some logic
Congestion model: Most of the business logic is in DO
Bleeding model: no Service, common in C++
Principle: Business objects encapsulate the internal business logic, while application services encapsulate the business logic of external business objects
conclusion
Domain model is more suitable to reflect the nature of the real world, so it is very suitable when the business domain is very complex, but at the same time, domain model puts forward higher requirements on the technical ability of designers. So it’s hard to see the domain model in our general business systems development.