Should the data access layer know the domain?

Question

We are developing a web application following Domain-Driven Design and layered software architecture, with the following layers:

• presentation (REST API)
• domain (entities, value objects as defined in DDD with domain-specific behavior)
• data access (DAO classess accessing the database)

Each of the above is a separate maven module, with a downward dependency, i.d. presentation depends on domain and domain on data access.

Should the data access layer return instances of the domain classes or should there be an isolation between the domain and data access layer?

Answer 1

Yes, your infrastructural layers should know everything about your domain. Concrete repository classes support your abstract domain interfaces by providing the necessary implementation required.

Your infrastructure layer will have a dependency on your domain layers.

A great architectural pattern to help you in domain-driven design is that of the Onion Architecture. Read this article by Jeffery Palermo.

Answer 2

One common persistence abstraction in DDD is to use the Repository pattern.

You would define the repository's interface in the domain and the contract would be based on domain concepts. Therefore, yes you pass aggregate root entities directly to the repository and query methods can also return aggregate roots directly.

Note that the repository implementation would live in the infrastructure layer, not the domain.

Answer 3

In the long term it's always better to separate concerns. Domain interfaces are there for the clients of the domain to perform domain-specific tasks, while data access layer is there to store and retrieve objects to/from the persistent storage. In case domain interfaces are used for persistence as well, implementation details can easily leak up into the interfaces of the domain.

To me, the layers of DDD is more about the organization of the public interfaces (contracts) than how internal implementation is provided. From this point of view, it's not important if the internal implementation is in the same assembly - and thus layer - as the public interfaces, or is provided with dependency inversion. These - and where the implementation is - are merely implementation details.