I\'m trying to get my head around how to properly use the repository pattern. The central concept of an Aggregate Root keeps coming up. When searching both the web and Stack
Aggregate is where you protect your invariants and force consistency by limiting its access thought aggregate root. Do not forget, aggregate should design upon your project business rules and invariants, not database relationship. you should not inject any repository and no queries are not allowed.
In another world, in Event Sourcing, an Aggregate(Root) is a different concept. Event Sourcing might be encountered together with CQRS, DDD etc.
In Event Sourcing an Aggregate is an object for which the state (fields) is not mapped to a record in a database as we are used to think in SQL/JPA world.
Is not a group of related entities.
It is a group of related records like in a history table.
GiftCard.amount is one field in a GiftCard Aggregate, but this field is mapped to all the events, like card-redeemed (take money from the card) ever created.
So the source of data for your Aggregate is not a record in a database but the complete list of events ever created for that specific aggregate. We say we event sourced the aggregate.
Now we can ask ourselves how is it done? Who is aggregating these events so we are operating still with one field e.g GiftCard.amount? We might be expecting that amount to be a Collection and not a big-decimal type.
Is the event sourcing engine, doing the work, who might simply replay all the events in the creation order. But this is out of the scope for this thread.
Dinah:
In the Context of a Repository the Aggregate Root is an Entity with no parent Entity. It contains zero, One or Many Child Entities whose existence is dependent upon the Parent for it's identity. That's a One To Many relationship in a Repository. Those Child Entities are plain Aggregates.
Aggregate means collection of something.
root is like top node of tree, from where we can access everything like <html>
node in web page document.
Blog Analogy, A user can have many posts and each post can have many comments. so if we fetch any user then it can act as root to access all the related posts and further comments of those posts. These are all together said to be collection or Aggregated
From a broken link:
Within an Aggregate there is an Aggregate Root. The Aggregate Root is the parent Entity to all other Entities and Value Objects within the Aggregate.
A Repository operates upon an Aggregate Root.
More info can also be found here.
If you follow a database-first approach, you aggregate root is usually the table on the 1 side of a 1-many relationship.
The most common example being a Person. Each person has many addresses, one or more pay slips, invoices, CRM entries, etc. It's not always the case, but 9/10 times it is.
We're currently working on an e-commerce platform, and we basically have two aggregate roots:
Customers supply contact info, we assign transactions to them, transactions get line items, etc.
Sellers sell products, have contact people, about us pages, special offers, etc.
These are taken care of by the Customer and Seller repository respectively.