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).
Performing CRUD Operations
There are some mandatory operations, which must be implemented by the Repository, together they allow all CRUD operations to be performed. Let’s take a look at the typical Base Repository and methods it provides.
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 which abstracts away the storage and focuses on providing and managing Plain Old Objects (POO).