Edition 0 Updated to asp. Net core 0

Additional resources 
•
Martin Fowler. Value Object pattern
https://martinfowler.com/bliki/ValueObject.html
 
•
Value Object
https://deviq.com/value-object/
 
•
Value Objects in Test-Driven Development
https://leanpub.com/tdd-ebook/read#leanpub-auto-value-objects
 
•
Eric Evans. Domain-Driven Design: Tackling Complexity in the Heart of Software.
(Book; 
includes a discussion of value objects) 
https://www.amazon.com/Domain-Driven-Design-Tackling-Complexity-
Software/dp/0321125215/
 
The Aggregate pattern 
A domain model contains clusters of different data entities and processes that can control a 
significant area of functionality, such as order fulfillment or inventory. A more fine-grained DDD unit is 
the aggregate, which describes a cluster or group of entities and behaviors that can be treated as a 
cohesive unit. 
You usually define an aggregate based on the transactions that you need. A classic example is an 
order that also contains a list of order items. An order item will usually be an entity. But it will be a 
child entity within the order aggregate, which will also contain the order entity as its root entity, 
typically called an aggregate root. 
Identifying aggregates can be hard. An aggregate is a group of objects that must be consistent 
together, but you cannot just pick a group of objects and label them an aggregate. You must start 
with a domain concept and think about the entities that are used in the most common transactions 
related to that concept. Those entities that need to be transactionally consistent are what forms an 
aggregate. Thinking about transaction operations is probably the best way to identify aggregates. 
The Aggregate Root or Root Entity pattern 
An aggregate is composed of at least one entity: the aggregate root, also called root entity or primary 
entity. Additionally, it can have multiple child entities and value objects, with all entities and objects 
working together to implement required behavior and transactions. 
The purpose of an aggregate root is to ensure the consistency of the aggregate; it should be the only 
entry point for updates to the aggregate through methods or operations in the aggregate root class. 
You should make changes to entities within the aggregate only via the aggregate root. It is the 
aggregate’s consistency guardian, considering all the invariants and consistency rules you might need 
to comply with in your aggregate. If you change a child entity or value object independently, the 

---

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: