Repositories abstract database access
A Repository object abstracts the Domain Model's access to the database. It hides the complexities of the database, making the model more testable. At the same time, it prevents details related to the underlying database or persistence mechanisms from slipping into the Domain Model.
Repository objects adhere to the principle that infrastructure concerns should be injected into the application as dependencies. They allow database dependencies to be made available dynamically in real time.
Constructing the Domain Model before thinking about persistence helps focus remain on the business problem. It also helps create and evolve the Domain Model, and only worry about technical aspects like migrations and foreign keys when the design is stable.
Delinking the persistence layer also helps us switch or replace underlying technologies with minimal disruption to the domain model. The Repository layer is rewired to accommodate the new database technology, and existing integration or API tests help discover and fix bugs faster.
Repositories map one-on-one with Aggregates, and are tied to specific database technology. A system may have more than one implementation of a Repository if it uses more than one database. The correct Repository implementation is dynamically injected into the persistence layer as a dependency during runtime.
Repositories can be of two types:
- Collection-Oriented Repository objects behave as if data is entirely available in memory as a collection. It is responsible for tracking data changes, saving data to the database, and loading data when necessary. It simplifies the persistence mechanism for an application by taking over the complexities.
- Persistence-Oriented Repository objects require the system to explicitly load and persist data. They are handy when one is dealing with persistence mechanisms that don't implicitly or explicitly detect and track object changes.
The Repository object should persist and load the entire object collection associated with Aggregates as Aggregates are loaded in entirety . Apart from knowing the persistence mechanism for the database in use, Repository objects also understand the relationship between the Aggregate objects. This translates to knowing structures in the database and their order of persistence.