DAO, Repositories and Services in DDD

Question

After reading several articles, I am starting to understand the difference between DAO and Repositories, but I find myself in trouble trying to understand the difference between Repositories and Services.

For putting in short terms, in the OO paradigm:

• DAO : Class that contains the basic CRUD operations for one entity class. It has the necessary code to get or retrieve things of the underlying persistent storage system. Generally speaking, the methods receive object entities as parameters, except in the retrieve method where using a type of the Identifier is valid.

• Repositories : In a higher level of abstraction.. as generally I have read is a kind of place where put code that handle operations over aggregate objects (objects that have child objects). It uses the DAOs to retrieve objects from the database, and in the end it exposes an interface in the domain "business" language. (But again, I think it is very valid to use data types of ids). Example : A very simple addSomething where something is a child object of the parent whose instances, btw, are managed as a whole by the Repository.

• Services : Again, it is in a higher level of abstraction. To my humble point of view they are a good place to connect two classes that do not share parent-child relation, but is as far (in abstraction terms) as Repository. Example : The method transferCash between two bank accounts.

So, that's are my readings about, but I am asking here the above thoughts are right or not. Or how I should think. Or something that points me to really understand the difference of all this concepts.

Some of the sources :

• http://debasishg.blogspot.com.ar/2007/02/domain-driven-design-inject.html
• http://warren.mayocchi.com/2006/07/27/repository-or-dao/
• http://www.sapiensworks.com/blog/post/2012/11/01/Repository-vs-DAO.aspx
• What is the difference between DAO and Repository patterns?

Answer 1

Repositories are - like you say - an abstraction. They originate from Martin Fowler's Object Query Pattern. Both Repositories and DTOs can simplify database persistence by mapping persisted data to equivalent collection of entity objects. However, Repositories are more coarse-grained than DAOs by providing control of an entire Aggregate Root (AG) often hiding a lot of internal state from the client. DAO's on the other hand can be as fine-grained as being dedicated to a single entity object. For both Repositories and DAOs it is common to use Hibernate or other Object/Relational Mapping (ORM) Frameworks instead of writing your own implementation.

Typically, services can reside in a Service Layer and can act both as a functionality facade, anti-corruption layer and coordinator for caching & transaction. They are often a good place to conduct logging. Services coarse-grained and usecase-oriented, e.g. Service.updateCustomerAdress() or Service.sendOrder(). Repositories can be too fine-grained for clients to consume, e.g. Customer.add(…), Order.modify(…).

Repositories and DAOs have the same purpose - to persist data permanently. Services on the other hand should be ignorant of persistence and have no knowledge about your database. They usually work tightly together with domain services, repositories, domain core.

Answer 2

Repositories are interfaces for storing and retrieving Aggregate Roots (AR), not single Entities. You have one Repository for each AR of your Domain Model.

As per Fowler's Repository Pattern, repositories act like in-memory objects collection and this is one of the main differences comparing them to DAOs.

Repositories interfaces are a means for Domain Model's client (and thus are part of the Domain Model) to get start working with the Domain Model. Client's are intended to get an AR instance from a Repository, call some method on it, which usually modify its internal state, and then store it back to the Repository.

Answer 3

I'm not sure what "DAO" even is. Repositories are an abstraction for loading entities. You should be able to Get an entity and Save one, that is it. No querying. If you want to query some data, write a query (maybe even within an MVC action method, or with the simplest of simple abstractions allowing some SQL to be executed and some DTOs returned that can be rendered straight into the HTML).

Services on the other hand are tricky. For a start the term is overloaded. "Application Services" as defined by the DDD book by Eric Evans exist because objects in the Domain Model are not allowed to access infrastructure concerns like databases, messaging, caching etc. They need all of that stuff done for them and handed to them on a plate, and Application Services do just that. Application Services, for their part do not contain any logic. I would not expect to see ICustomerService.ChangeAddress() do anything other than:

1. Load the Customer entity.
2. Call Customer.ChangeAddress(newAddress) <- this encapsulates the domain logic
3. Save the customer.
4. Perhaps publish some events.

If you have a service that is loading a customer, setting it's Address property and saving it, then that service is actually a Transaction Script and the Customer is a DTO. Meaning you definitely have a leaky abstraction and likely have an anaemic domain model. Domain model objects should not have public setters, and when DDD is combined with CQRS, your domain model may not even have any public state at all beyond the main entity ID values.