Repository
Special way to obtain a collection of Aggregates together with their Child Entities.
Since Aggregate Roots are quite aware about their invariants, they have no idea about the persistence and how to be fetched and instantiated. They became Aggregate object only when some other instance make them, it’s just like you become a human, not because you want it, but because your parents do. The role of such parent is given to the Repository Service Object (not to be confused with Domain Service, Service Object is one that is stateless and may be injected into the other Service Objects).
Obtaining And Persisting Aggregates
Repository usually behaves like a collection of Aggregate Roots. It should provide the operations the domain actually needs, for example finding a Cart by identifier and saving a changed Cart. It does not have to expose generic CRUD for every field, because that would push persistence concerns back into the model.
As the shared object, Base Repository lays somewhere where it is globally available. Usually in some shared or common directory holding base classes.
Sql Repository is a thin abstraction, having all abstract method’s concrete implementations. It uses some kind of SQL client, may be the one from the ORM.
Cart Repository class is our Interface, an API exposed to the module. To abstract away storage engine, you must always refer to Cart Repository, not to its concrete implementation. Which in fact is hidden and can be grabbed only via helper method get_cart_repository().
Summary
So, there we have learned about another DDD building block, which brings Aggregate Roots to life. It is responsible for obtaining and persisting Aggregates. A dedicated Service Object abstracts away the storage and focuses on providing and managing plain domain objects.