203
CHAPTER 6 | Tackle Business Complexity in a Microservice with DDD and CQRS Patterns
aggregate root cannot ensure that the aggregate is in a valid state. It would be like a table with a
loose leg. Maintaining consistency is the main purpose of the aggregate root.
In Figure 7-9, you can see sample aggregates
like the buyer aggregate, which contains a single entity
(the aggregate root Buyer). The order aggregate contains multiple entities and a value object.
Figure 7-9. Example of aggregates with multiple or single entities
A DDD domain model is composed from aggregates, an aggregate can
have just one entity or more,
and can include value objects as well. Note that the Buyer aggregate could have additional child
entities, depending on your domain, as it does in the ordering microservice in the eShopOnContainers
reference application. Figure 7-9 just illustrates a case in which the buyer has a single entity, as an
example of an aggregate that contains only an aggregate root.
In order to maintain separation of aggregates and keep clear
boundaries between them, it is a good
practice in a DDD domain model to disallow direct navigation between aggregates and only having
the foreign key (FK) field, as implemented in the
Ordering microservice domain model
in
eShopOnContainers. The Order entity only has a foreign key field for the buyer, but
not an EF Core
navigation property, as shown in the following code:
Dostları ilə paylaş: