Byte Interview: Talk about how to design aggregation and aggregation roots

The author of this article analyzes the byte interview questions, explains the basic concepts of aggregation and aggregation roots, and introduces some design principles and how to design and use them.

1. Aggregation

In Domain-Driven Design (DDD), aggregation is a core concept that helps developers manage complexity, especially when dealing with a large number of related objects.

Aggregations are made up of closely related entities and value objects, and are the basic units for modifying and saving data. Each aggregate has a repository that holds the aggregated data.

Aggregation has an aggregation root and context boundary, which defines which entities and value objects the aggregation should contain according to business needs and cohesion principles, and the aggregation is loosely coupled with each other, so that the microservice design will naturally achieve high cohesion and low coupling.

Aggregates are part of the domain layer in the DDD layered architecture, and the domain layer can contain multiple aggregates that work together to implement the core business logic. The entity implements business capabilities in the aggregation with a congestion model to ensure high cohesion of business logic.

Business logic across multiple entities is implemented through domain services, and business logic across multiple aggregates is implemented through app services.

2. Aggregate roots

In the traditional data model, each entity is independent. If entities are modified and invoked at will, it can lead to inconsistencies in data logic. The way locks are used can complicate the software and slow down system performance.

Think of the aggregate root as the head of the department, which is not only the entity but also the manager of this aggregate "department".

When an aggregate root is an entity, it has its own properties and business behaviors that execute its own business logic.

When the aggregate root acts as the manager, it coordinates entities and value objects within the aggregate, completing the business logic according to fixed business rules.

When aggregations collaborate with each other, the aggregate root is the external interface. It accepts external requests by associating other aggregates with its own ID. If you need to access other entities within the aggregate, you must first access the aggregate root, and then navigate to the internal entities of the aggregate. External objects can't directly access entities inside the aggregate.

3. Some design principles for aggregation

When designing an aggregation, there are a few core principles that can be followed to ensure that the aggregation is valid and consistent.

1. Select the appropriate aggregate root

Each aggregate should have an aggregate root, which is the most important entity in the aggregate, and other entities and value objects are associated through the aggregate root. The aggregate root should be an entity that represents the entire aggregate and is responsible for ensuring the consistency and integrity of the data within the aggregate. When choosing an aggregate root, you should consider which entity plays a central role in the business and can effectively manage and encapsulate the behavior of the aggregate.

2. Polymerization minimization

The aggregate should be as small as possible, containing only the entities and value objects that must be managed directly by the aggregate root. This reduces the complexity inside the aggregate, improves the cohesion of the aggregate, and makes small aggregates easier to understand and maintain.

3. Encapsulate business rules

The aggregate root should encapsulate the business rules inside the aggregate, and any modification to the data inside the aggregate should be accessed through the method of the aggregate root, and all business rules should be enforced correctly after the method is executed. In this way, the aggregate root ensures that the state of the aggregate is always consistent.

4. References between aggregates are by identifiers

Aggregates should not directly reference each other's entities, but rather by identifiers such as IDs. Doing so helps reduce coupling between aggregates, allowing each aggregate to change and scale independently without affecting other aggregates.

5. Definition of Consistency Boundaries

When designing an aggregate, it's important to be clear which operations must be strongly consistent, i.e., the state of the aggregate must be consistent after the operation is completed, which involves transactional operations. Aggregations should have a minimum consistency boundary, and any transactions should only be completed within the scope of a single aggregation and should not span aggregation operations.

Fourth, how to design and use aggregates and aggregate roots

Let's take the order system of an e-commerce platform as an example to see how aggregation and aggregation roots are designed and used.

In an order system, orders are often used as aggregation roots, because orders are the most central business objects in the entire business process.

Order aggregation includes multiple entity objects, such as order details, payment information, receipt information, and so on.

Order details: Entities within an aggregation, where each order detail represents a purchase item in the order. It includes the item ID, quantity purchased, unit price, and subtotal. Order details are tightly tied to orders, and their lifecycle is managed by the order aggregation root.

Payment information: It is also an entity within the aggregate, and the payment information records the payment method (such as credit card, Alipay, WeChat Pay), payment status, payment amount, and payment time, etc., which is essential for completing transactions and conducting financial accounting.

Receipt Information: Typically a value object that contains information such as province, city, street, and zip code. Because it doesn't have a separate identity, it just describes a geographic location.

By designing the right aggregations, the business operations of the order system will be very clear and able to be centrally managed.

Here are some common business practices that describe how aggregations are used.

1. Order creation operations

When a customer selects an item and submits an order, the system triggers the order creation process.

The system first creates a new order aggregation instance with the order as the aggregation root. The order aggregation root contains the necessary information, such as the order number, the initial status of the order, and so on.

Each item selected by the customer is added to the order as an order item. Each order detail entity includes information such as product ID, purchase quantity, and unit price. These order details are dynamically managed by the order aggregation root during the creation process, ensuring data integrity.

The shipping address provided by the customer is created as a value object and associated with the order aggregation. At the same time, the initialized payment information will also be set to an entity, including information such as payment method and payment status.

2. Payment Processing

When a customer makes a payment, the payment information entity is updated, including recording the payment amount, payment method, payment time, etc. The order aggregation root ensures that the payment information is consistent with the status of the order.

After the payment is successful, the order aggregation root will update the order status to "paid", which is done through the business logic inside the aggregation to ensure that all data is consistent.

3. Shipment processing

When an order is ready to be shipped, the order aggregation root verifies the completeness and accuracy of the stored ship-to address information. If the address is incomplete, the customer may be asked to provide additional information or a second confirmation.

Once the ship-from address has been verified and the item is ready, the order aggregation root updates the order status to "Shipped". Subsequently, the actual logistics operations begin and the process information of the shipment is recorded and tracked in the system.

This article was originally published by @汤师爷 on Everyone is a Product Manager. Reproduction without permission is prohibited.

The title image is from Unsplash and is licensed under CC0.

The views in this article only represent the author's own, everyone is a product manager, and the platform only provides information storage space services.