DDD Practice Manual (4. aggregate aggregate)

Link to the original text ：DDD Practice Manual (4. Aggregate — polymerization )

In the last article, I introduced DDD Core concepts in ,Entity Entity and Value Object The concept of value object , And how to implement them in the project . And in this article I will introduce DDD Another core concept in the book ,Aggregate polymerization .

What is? Aggregate ？

Actually Aggregate It's a pattern , The specific form implemented in the code is very simple , In two parts , The first is to define a Entity, As Aggregate Root, It is generally called aggregation root . The second part is to follow Aggregate Integrity rules operate on domain data .

Before we begin to introduce the specific implementation , Let's first think about why we use Aggregate Such a pattern , What kind of problems can it solve for us .

Imagine a business scenario ,「 The customer increases the insured amount 」. From the perspective of code implementation , You can do this : adopt 「 Insurance policy number 」 Get the customer's policy information , Then obtain the corresponding insurance product information , Then modify the corresponding 「 Coverage 」, Then modify the amount to be paid 「 premium 」, Finally, you need to update 「 The insured 」 Information about . In fact, it is not difficult to realize such requirements , If you think about using DDD The way , We will design 3 Different Entity object , Insurance policy (Policy), Insurance products (Product), And the insured (Insured). Then similar code may be as follows :

policy.increaseInsuredAmount(xxxx);
product.changePremium(yyyy);
insured.updateBill();

There is nothing wrong with the function of such code , But from the perspective of design, it is really worth discussing . from 「 The customer increases the insured amount 」 From the realization of , Need to involve multiple Entity Data update , The problem with the above code is that the logic of updating these data is scattered and exposed in the code , When subsequent business requirements change , It's hard for developers to understand the business from the code , Thus causing omissions and errors .

In the design method or API On , We know the method or API The particle size should not be too fine , Sometimes you need to design a coarse-grained approach , Hide the implementation logic under this method , Instead of exposing it to clients . When Entity When the data of , The same idea should be followed . In many business scenarios ,Entity The data between should be consistent , In the example above , After the business operation of increasing the insured amount , Policy , product , The insured Entity The data status of should be consistent according to business rules , There should be no increase in coverage , But when the premium remains unchanged .

that Aggregate How to solve this problem ？ This is something to understand Aggregate The integrity rules of .

Aggregate Integrity rules for

The so-called integrity rule consists of the following two points :

• All code can only pass through Aggregate Root, That is, the aggregation root, this special Entity Access to the system Entity, You can't operate any Entity.
• Every 「 Business 」 Only one range can be updated Aggregate Root And its associated Entity state .

Let's explain these two rules one by one .

First look at the first , It's easy to understand , Simple implementation is also very simple . Refer to the previous example , We can 「 Policy 」 Object as Aggregate Root, and 「 product 」 And 「 Insured 」 As this Aggregate Root Internal member variables . Only 「 Policy 」 Method on object . The modified class diagram is as follows :

And the code becomes :

policy.increaseInsuredAmount(xxxx);

and policy Of increaseInsuredAmount The internal implementation of the method is :

public void increaseInsuredAmount(BigDecimal insuredAmount) {
    this.product.changePremium(yyyy);
    this.insured.updateBill();
}

You can see that in the code , We no longer operate on different... One by one Entity object , But only through policy Object completes the whole business logic , Data integrity is related to business rules Aggregate Root Of policy The object guarantees .

On the basis of understanding the first rule , Let's take a look at the second rule . The second rule is actually well understood literally , Is within a transaction scope , We can only update one Aggregate Root And the data related to it . To simplify the problem , The transaction here refers to the transaction of relational database .

But these two integrity rules will lead to some design trade-offs , You have to figure out how to solve these design problems on the actual project .

Aggregate The design of the

When you need to implement Aggregate Mode time , The first problem you need to solve is to find the right one Aggregate Root. On this issue, whether it is Eric Evans Or something else DDD None of the books give a clear answer , They all give some examples , But there is a lack of a clear methodology to help architects design Aggregate Root. The advice in the book is 「 Not too big , It can't be too small 」, It's actually the same as what I didn't say . If Aggregate Root The design is too large , Then no matter what business rules are implemented, they should assemble the same Aggregate Root object , There must be a lot of code that is redundant and useless . But if the design is small , For example, each Entity It's all one Aggregate Root, Then it is difficult to update only one transaction Aggregate Root The requirements of .

My experience in the project is in the early stage of design , Try to control Aggregate Root Size , Don't associate too many Entity, Cause to appear 「 God class 」 In this way Entity. When business logic changes , Need to update additional Entity When the state is more abundant Aggregate Root Correlation relation of . If the project will Domain And PO Separate , In the design Aggregate Root The advantage is obvious , It does not need to be coupled with the relational data structure of the persistence layer , In the Repository Free assembly .

And another design Aggregate Root The method of is developed in recent years 「 Event storm 」, As a methodology , It can help architects work with business people to find those suitable for Aggregate Root The object of . How to use it 「 Event storm 」 I'll explain in a later article .

The second design consideration is to define the transaction scope in which part of the hierarchical architecture . According to the layered architecture I introduced earlier , It is recommended to put transaction control in application service That floor , Consistent with the granularity of a business use case .

In actual projects 「 Only one transaction can be updated at a time Aggregate」 The restrictions will be more stringent , Because when you put transaction control on application service That layer means that each use case can only update one Aggregate, Under this limitation, we need to design a reasonable Aggregate It's hard , Sometimes it's impossible . If you must update more than one in one transaction Aggregate What to do ？ In general, I suggest there are two options .

Field events — Final consistency

This is a DDD A way recommended in books , The way domain events are used is to integrate individual Aggregate Updated events are broadcast , There are other corresponding hadler Update your responsibility after receiving it Aggregate. Due to the breaking of transaction consistency , Some kind of mechanism is needed to guarantee Aggregate Data consistency .

The problem with using this solution is that you need to introduce a solution for the ultimate consistency of transactions , This will undoubtedly increase the complexity of the system . Second, if only to meet a single transaction and Aggregate To break away from business rules and write a lot of rules to deal with events handler, Then there is no doubt that it is a bit of abandoning the basics , in order to Aggregate and Aggregate 了 .

Break the rules

The second is not a solution , It's easy to implement , Is to break each transaction can only be updated Aggregate The limitation of , stay application service Multiple can be updated in a single transaction in Aggregate.

But this is not completely unlimited , We still have to follow, only through Aggregate Root quote Entity The rules of , And control application service Can access Aggregate Root The number of , According to project experience 3 The following are acceptable .

Summary

Aggregate yes DDD A very important and unique concept in , It encapsulates Entity Data consistency , This is also the most direct embodiment of the business rules at the system code level . And from Aggregate Start , The value of business knowledge in analysis has gradually begun to reflect . How to design a reasonable granularity Aggregate It requires rich business knowledge and system analysis experience , And as the business grows Aggregate We should also constantly refactor .

The next one will be DDD The last article on domain objects in , I'll show you how to use... In a project Factory And Repository Realization Entity Life cycle management , I hope you won't miss .