There is a lot of buzz around Domain-Driven Design’s Repositories. It feels to me though that there is still a lot of misunderstanding about the concepts and the patterns promoted by the book.
Domain-Driven Design is not an easy read and the concepts presented by Eric Evans rely a lot on very good understanding of what is Object-Orientation. That’s why I usually avoid talking about Repositories to experienced developers learning DDD concepts. I prefer to only touch this patter after they get a good grasp of what model driven design is all about. Every time I write something that touches the Repository pattern I often get more questions and comments than any other DDD topic. Most of those could be summarised in: what’s the difference between Repository and DAOs?
The main goal in Domain-Driven Design is to model objects as close to the domain -not necessarily the real world- as possible. Suppose we are developing areal estate application that manage properties for rent. Probably a “property” is an important concept is this domain so you would have an object to represent that. Same for rent, it is an important concept and has data (how much? for how long?) and behavior (what if it’s late? what happens on termination?) so it would probably e modeled as one or more objects.
In this application you will probably have an user story in your development backlog that says something like “show me all the properties for rent between $100 and $350″. When playing this story, the first issue a developer faces is usually: where are all the properties stored?
Let’s think about how we do things in the real world. In the real estate business, where do the business people keep the inventory of properties for rent? Probably they would keep it in some sort of archive. With no computers, people would have those big metal archives filled with lots of index cards with property details. The archive itself is an important part of how the business process is implemented but this is not part of the domain. In the domain there is a property inventory but the metal archive is just how it happens to be implemented.
When creating a Domain Model you will need something to play the role of that archive, and you will probably use a database for that. Since most databases aren’t object-oriented we generally use some infrastructure of mapping logic to perform the translation between objects and data. There are many possible ways to shape this mapping logic, the most common pattern is the Data Mapper, and we generally call those Data Access Objects or simply DAOs.
Just like the metal archive, DAOs are not business concepts. It is just a translating layer converting from objects to data and vice-versa. Your business experts should not have to know that you get properties from a DAO because this concept simply doesn’t exist in their world.
Eric Evans’ proposed solution is to create the abstract concept of a Repository. A Repository is some virtual place where the Entities (the most relevant objects in a domain) are stored. Business classes are aware of the Repository; they know it’s the place where they should look for business objects. How the Repository is implemented simply doesn’t matter. Domain classes must never refer to that implementation but only to the interface.
In a heavily typed language like Java I’d suggest that the Repository must be modeled as an interface. What about the actual implementation? Well, it depends. If you have only one persistence engine (say a RDBMS) you can probably just have a DAO that implements that interface.
The hardest thing about Domain-Driven Design is that you have to think in a different way. Instead of building the Domain Model on top of some software infrastructure you should start with the model and build the infrastructure to support it.
Repositories are business concepts and DAOs are infrastructure.