–Updated 27/09/2010
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.
What clarifies the thing about the repositories is when I use to explain it like this:
I have for instance a root agregate that is an Order, so a I would like to refer to a collection of all the orders that may exist, in human language we already have this concept, so I can call it Orders, that is the collection of orders, and this is my repository.
There I have ways of getting information derived from this collection in a domain oriented way, like I would like to know how many orders are due?, or what are the orders from this particular customer?, or things like this, that we already do in our language.
Juan.
I used a similar strategy once, Juan. I teached a class to beginners on OO modeling and I explained Entities, Aggregates, Value Objects but skipped the Reository. After a little nonsense modelling exercises (like modellin cats, mammals and th like) I introduced to concept of “List”of things. First I got they using the standard lists provided by the language API (like ArrayLists) and then introduced complexity that made that strategy unfeasible (like query objects/specifications).After that I introduced ORM and the DAO. It worked smoothly
Congratulations.
Finally I (guess) undestood this confunsion.
Thanks Phillip, there’s so misunderstanding about the difference between DAO and Repository and your post clarify that.
Hi Phillip,
Your article didn’t ring true with me, and I realise it’s because your definition of a DAO (as a Row Mapper) is different to what I’ve always thought a DAO was (which is much closer to the concept of a Repository).
To illustrate, here’s the type of methods I’d expect to see in a Person DAO (i.e. mainly CRUD methods):
public interface PersonDAO {
// Returns the Person having the given ID
Person get(int personID) throws PersonNotFoundException;
// Deletes the Person having the given ID
void delete(int personID);
// Returns the people matching the given search criteria
List getPeople(List);
// Adds the given Person (must not have an ID)
void add(Person person);
// Updates the given Person (must have an ID)
void update(Person person);
// etc etc.
}
This interface could be implemented in lots of ways:
- using a simple in-memory List of Person objects
- using hand-written SQL (e.g. JDBC in the Java world)
- using an ORM tool like Hibernate
The point is that the above DAO only concerns itself with domain concepts; there’s nothing in there about mapping or even a database. This is what a DAO means; it hides the details of persistence from the rest of the app. See this page about DAOs (the example they use happens to use a database, but that’s an optional implementation detail):
http://www.corej2eepatterns.com/Patterns2ndEd/DataAccessObject.htm
Row mapping might be a technique used internally within some DAO implementations, but that doesn’t mean DAOs and RowMappers are equivalent.
Given the above, I’m still none the wiser about the difference between a DAO and a DDD Repository. The only remotely plausible thing I’ve heard so far is that DAOs are fine-grained, i.e. you have one DAO per domain class (including Value Objects etc), whereas Repositories only exist for the Entities (aggregate roots) in one’s domain model. A repository would therefore be implemented by calling a number of related DAOs to assemble the required aggregates.
Hi, Andrew,
You are right: if you do not agree in the concept of a DAO I use it will be impossible to agree with the text
There are some different things here. You say a DAO is not aware of a database but is concerned only about persistence. Well, databases (Relational, Flat files, XML, doesn’t matter) are how we keep state nowadays so a DAO is probably dealing with databases. Keeping the object-to-data structures mapping into other object than the DAO may be a valid strategy in some cases but the DAO would still be aware of the fact that there is a database.
I don’t like much the link you sent, I refer sun.com’s page, but it says:
“Use a Data Access Object to abstract and encapsulate all access to the persistent store. The Data Access Object manages the connection with the data source to obtain and store data. ”
Even if you don’t consider a DAO to be a Data Mapper (what I strongly disagree, they are clearly Data Mappers for me) you still have them as the objects that deal with the persistence, connections and data sources. Well, persistence, connection and datasources are not business concepts, indeed we define a whole layer only for this aspect of a system.
We need to abstract the fact that objects need to be persisted and retrieved from the domain, it is a technical limitation and not a business concept. That’s why we use repositories: to abstract the very technical concept of persisting and retrieving objects from the business layer.
The DAO abstracts the technology used to persist but the Repository abstracts the fact that objects need to be persisted/retrieved at all.
If you have logic that belongs to a Repository (like calling multiple DAOs) if can be worth its own object but if you only use Repositories to provide Dependency Inversion Principle -very common- just making the Repository an interface implemented by a DAO would be sufficient.
Cheers
I see the problem of calling a repository by it’s implementation one more case of not using intention-revealing interfaces. After all the name of the interfaces is part of the interface, not only it’s member functions.
So using the concept of DAO instead of repository is just one more case of using the how instead of the what.
A DAO for example communicates that they retrieve Data, that they Access something and they are related to Objects. But what it really matters to me is to have a place to interact with the set of some concept I use in my domain, that’s all. This is valid even if this concepts are magically generated and don’t use a database, because we don’t care about this at the domain level.
I still don’t get it.
How would the repository similar to the mentioned PersonDAO look like in code ?
I bet it will be exactly the same except for the name.
Hi Albert,
To understand why use ‘Repository’ instead of ‘DAO’ you have to understand the core of Domain-Driven Design: the Ubiquitous Language. This is the language used by user and devs to model the system. It has to be simple and with as little noise as possible so the user can understand.
The DAO is a design pattern and one of the most aspects of design patterns are their name. When you say ‘UserDAO’ you are telling me that this class accesses some persistent storage to retrieve Users. We generally do not have the concept of ‘persistence’ in the Ubiquitous Language so the Repository abstracts it. The implementation of the Repository will probably use some kind of DAO but the concept that is used in the language is not tied to persistence, it pretends to be just a in-memory collection.