Comparison
Aggregate rootvsRepository pattern
Aggregate root
outside code holds a reference to the order and never to a line item, so every change goes through the order.
The single entity that acts as the entry point to an aggregate: external references point only at it, and it is responsible for the invariants across everything inside. That rule is what makes the boundary real rather than a drawing — if anything can reach an inner object directly, nothing is enforcing the aggregate's rules. Repositories are defined per aggregate root for the same reason.
Full entry →Repository pattern
the code asks for the customer as if from an in-memory collection, and where it actually came from is somewhere else.
An abstraction that presents stored aggregates as though they were a collection, so domain code queries objects rather than rows. It is a domain-driven design idea: one repository per aggregate root, with methods named in the language of the domain, not one per table. That is the real difference from a DAO — a repository is defined by the model it serves, a DAO by the storage it wraps — and it is lost the moment a repository grows a method per query the UI happens to need.
Full entry →