Question

The layering scheme for DDD suggests that the layers should be;

Presentation/Application/Domain/Infrastructure

The diagram presented in Evans book shows the Presentation accessing the infrastructure layer. Is my interpretation of this diagram correct in that any of the upper layers can be allowed the access any of the lower layers??

Answer 1

This question was posed using the word “layer,” so my initial answer addressed layers. It’s probably better to start out saying DDD is not about rigid layers, it is about building an application in a way that is easy to test and change because it encourages separation of concerns between different objects.

I don’t like calling the domain a “layer”, because the domain objects don’t really form a layer in the usual sense, they get passed around between the layers, but don’t belong to any of them. As far as having the presentation layer accessing infrastructure, the diagram is saying that it’s an option. It’s up to you how much to abstract access to the infrastructure from the presentation. In most cases I would tend to want to go through the application layer in order to avoid tying it to implementation details, but the direct approach is an option, the decision is up to you.

I think it’s a little frustrating reading Evans’ book because of the lack of concrete examples, but he is trying to make it broadly applicable, and some languages are a lot more flexible than others so they can do things differently. When using Java and Hibernate, for example, I don’t have any references from the domain to the data access objects, I think of the Hibernate persistent collection implementations as serving like repositories in allowing lazy traversal of the domain model. But that’s an implementation decision based on my choice of language and libraries, and other situations could justify different decisions.