concept
Keywords: strategic design, tactical design, domain driven, data-driven, domain model, domain object, value object, aggregation, aggregation root, Domain, subdomain, core domain, common domain, support domain, domain service, application service, event storm
What is the DDD
DDD domain-driven is not architecture, but an architectural design methodology.
In today’s microservices as the mainstream environment, a lot of times when we split microservices, we tend to split services based on intuition, experience, such as order services, user services, payment services.
However, these services only split the traditional single architecture into multiple single architectures. After long-term development of a service, the business becomes more and more responsible and the code becomes more and more bloated.
When the performance of some core services in a service is bottleneck, based on the concept of microservices, it may be necessary to extract the bottleneck services into separate services for horizontal scaling.
At this point, we found that the code and the business were too coupled, the boundaries between the businesses in the same service were not clear, and the separation cost was high. If you scale horizontally based on the entire service, the waste of server resources is serious, which is not conducive to the evolution of the architecture.
We just above in one of the multitude of problems encountered in the service architecture, until the emergence of DDD, through the domain modeling, borders areas, according to these areas boundaries micro service, very good to carry out the “high cohesion and low coupling” thought, it can guide our design field and application of clear boundaries, help us easier implementation architecture evolution.
Strategic design and tactical design
Strategic design: set up business domain model and divide domain boundary mainly from business perspective
Tactical design: mainly from a technical perspective, focusing on the technical implementation of the domain model, such as how to layer the code, including the implementation of the code logic of aggregation roots, entities, value objects, domain services, application services, etc
Design the aggregation
Taking the order creation scenario of e-commerce as an example, we simply analyze the business and implement the concepts of DDD:
- Use event storms to sort out all entities and value objects that create orders, such as users, merchants, goods, orders, shopping carts, and so on, based on business behavior
- To find outAggregate root, to determine whether an entity is an aggregate root, we can analyze whether it meets these elements:
- Independent life cycle
- Globally unique ID
- You can create and modify other objects
- There are specialized modules that manage this entity
- According to the principle of business single responsibility and high cohesion, find out all entities and value objects closely associated with the aggregation root, and build a set containing the aggregation root (unique), multiple entities and value objects, which is aggregation. Here we can construct four aggregations of order, user, merchant, commodity and shopping cart.
- Analyze the relationships between aggregations and draw object reference and dependency models. To create an order, it is necessary to have the recipient information and the receiving address. After the order is created, the two information will not be updated because of the user’s subsequent data update. Therefore, the user information and the receiving address are regarded as the value object of order aggregation. Similarly, commodity information is the same. Commodity and merchant are independent but closely related, and they are combined as the value object of the order. An order may contain commodities of multiple merchants, which belong to the same order. However, at the merchant end, orders of different merchants are isolated, so there are two objects: merchant order and user order. There is no direct relationship between the shopping cart and the order creation, and the domain event “Update Shopping cart” is triggered when the order creation is successful.
The above analysis may not make sense and is just an example of DDD domain analysis
Important concepts
entity
Entities in the domain model exist in the form of DO (domain objects), and each entity object has a unique ID that has business attributes and business behavior.
In the code, the entity class contains properties and methods through which it implements its business, usually in a congested model where all business logic related to the entity is implemented in the entity’s methods.
The value object
An object identified by the value of an object attribute that combines multiple related attributes into a single entity. It is read-only and immutable.
The aggregation
Aggregation is a combination of entities and value objects closely related to business and logic. It coordinates entities and value objects to work together to ensure that they implement common business logic and ensure data consistency.
The aggregation in the DDD domain layer belongs to the domain layer, which contains multiple aggregations that work together to implement the core business logic.
If the business needs to be implemented jointly by two entities within the same aggregation, we can implement it with domain services.
If the business needs two aggregate implementations together, we can compose the two aggregate implementations with application services.
Aggregate root
The aggregation root is also an entity and is the manager of the aggregation. It owns the attributes and business behavior of the entity.
As the manager of the aggregation, it can coordinate all entities and value objects within the aggregation and collaborate to complete the business logic according to fixed rules.
The difference between entity, value object, aggregate root
An aggregate root is also an entity that has a globally unique identity and a life cycle that belongs to the aggregate to which it belongs.
Entities are uniquely identified within the aggregation, and their life cycle is managed by the aggregation root with variable data.
Value objects have no unique identity, their life cycle is managed by the aggregation root, and their data is read-only.
The aggregate root is associated with the aggregate root by ID.
Aggregate root and its internal entity, direct object reference.
Aggregate root and its internal value object, direct object reference.