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.

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.

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.

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

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.