Lots of buzz about Domain-Driven Design’s repositories around. Most of those are misunderstandings of the concepts -and specially the patterns- defined by the technique. Domain-Driven Design is not an easy book to read and the concepts presented by Eric Evans relies a lot on a very good understanding of what is Object-Orientation and it is not easy to be found.
That’s why I usually avoid teaching about Repositories to experienced students -that already know he DAO or Data Mapper- until they get a real idea on what model driven design is about. Of all articles I wrote about Domain-Driven Design the Repository pattern is always where I get more questions and all of those are about the difference between Repository and DAOs.
The thing about Domain-Driven Design is to model objects as much like the domain as possible. Suppose we’re developing an application that would manage flats for rent. Probably a “flat” is an important concept is this domain so you would have an object to represent that. Same thing about rent, it is an important concept with its data (how much? How long?) and behavior (what if late?) so it would probably e modeled as one or more objects.
At this application you will probably have an user story that includes something like “show me all the flats for rent between $100 and $350. The first question to be asked is: where are all the flats stored?
Think about the real world. In the real renting business where are the flats the be rent? The easiest place would be… a paper archive. Without computers people would have those big metal archives filled with lots of cards with flat details. But this is not he domain, it’s only how we are used to think of it given the resources.
In the real business world there is no such a thing as the flat archive. Lacking this concept is not a problem to businessmen but developers will find hard to get those objects that represent flats coming from… nowhere.
You can say that in a system those will be stored at a database. That’s fine; databases easily store those kind of thing. Since databases generally aren’t really object-oriented we generally use a infrastructure of expert objects to perform the translation between objects and data. Probably the most used infrastructure is based on the Data Mapper pattern, we generally call those Data Access Objects or simply DAOs.
The problem is that a DAO is not a business concept. It is merely a way of translating objects to data and vice-versa. You can’t talk to a businessman that you get your flats from a DAO because this concept simply don’t exist on his world.
Eric Evans’ 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 now about the Repository, it is the place where they should look for objects.
To Domain-Driven Design, the implementation of a Repository simply doesn’t matter. What matter is that domain classes would never refer to that implementation but 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 probably can write a DAO that would implement that interface but if you have a more complicated scenario probably you’d it would be better to have a class implement that.
The hardest art of this all is that to apply DDD you have to take a different path than we are used to. You have to start thinking about the Domain Model and then create implementations that support that model.
Repositories are business concepts and DAOs are infrastructure. Infrastructure will be needed to support business concepts.
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.