In order to realize software design and software development under a unified idea and rhythm, there should be a lightweight framework to make certain constraints on the development process and code writing. Although DDD is a software development methodology, not a specific technology or framework, it is still necessary to have a lightweight framework. In order to develop a ddD-enabled framework, you first need to understand the basic concepts and core components of DDD.

I. What is Domain Driven Design (DDD)

First, understand that DDD is a development concept, the core of which is to maintain a model that reflects the concept of the domain (the domain model is the core part of the software and reflects the business nature of the software), and then guide the design and development of the model through a number of patterns.

The general process of DDD is to first generate a domain model (classes, properties of classes, relationships between classes) from a software requirements specification or prototype. Then based on the pattern (how should it be layered? Where is the domain logic written? How does it interact with persistence? How to coordinate multi-object domain logic? How to decouple logic from data storage, etc.) to implement code models.

Why use DDD

DDD can cope with complexity and rapid change:

1. Realize layering from technical dimension: it can pay attention to its own things at each layer, such as business logic at the domain layer, persistent data at the warehouse, use cases at the application service layer, and things exposed to the front end at the interface layer.

2. Business dimension: By dividing a large system into multiple contexts, different teams and different people can focus only on the development of the current context.

3. Time dimension: rapid verification and correction through agile iteration.

DDD core components

1. Boundary context: Firstly, the large system should be divided into multiple boundary contexts. For example, the direct selling system of the big health industry can be divided into several boundary contexts such as product, distributor and order, and each boundary context has its own domain logic, data persistence, use cases and interfaces. Each boundary context has different implementation methods according to its characteristics. For example, some boundary context basically has no business logic, that is, add, delete, change and search. The simplest CRUD mode can be used. Some bounded scripts have certain business logic, but have no requirements for high concurrency and high performance, then you can use classic DDD mode. The CQRS mode can be enabled for bounded contexts that have certain business logic and high performance requirements.

2. Entity: has a business life cycle and is tracked by a business identifier. For example, an order is an entity, an order has a life cycle, and an order number uniquely identifies itself. If all the attribute values of two orders are the same, but the order number is different, they are also different entities.

3. Value objects: No business life cycle, no business identifier, usually used for pattern entities. For example, the delivery address of the order, the amount paid by the order, and so on are value objects.

4. Services: Stateless, behaviorless, usually a single use case to coordinate multiple domain logic completion functions.

5. Aggregation: Multiple entities and value objects are usually combined into an aggregation to express a complete concept, such as order entity, order detail entity, and order amount value object, which represent a complete order concept and have the same life cycle, and need to be persisted uniformly to the database.

6. Aggregation root: Entities expressing general concepts in aggregation are made into aggregation roots, such as order entities. State changes of all entities in aggregation must go through the aggregation root, because the aggregation root coordinates the logic of the entire aggregation to ensure consistency. Of course other entities can be called by external direct temporary queries.

7. Services: Coordinate business logic between aggregations and complete use cases.

8. Warehousing: Used to persist aggregates, usually with one repository per aggregate root. Warehousing is a good way to decouple domain logic from databases.

9. Factory: Used to create complex domain objects and can protect the complex creation process of domain objects.

DDD combat advanced video please pay attention to wechat public number: MSSHCJ