Domain Driven Design

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开发者_StackOverflow中文版 can be allowed the access any of the lower layers??

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.

Hmm, IMHO DDD is not so much about 'layering'. It's more about modelling the problem you're trying to tackle in a good way, so that your model (entities, value objects, repositories, services, specifications) reflect the real world problem-domain.

However, there is indeed some kind of 'separation' between the classes you write, but I really wouldn't go so far as calling it 'layering', since IMHO it is perfectly OK that your presentation classes and domain classes access the infrastructure for instance. However, the domain classes should have no dependency on the presentation classes for instance, but the opposite can be true ofcourse.

I mostly organize my projects in this way:

• a have an assembly which contains the presentation related stuff. (Forms, etc...)
• I have an assembly which contains the 'domain'. This includes entities, repository- interfaces, specification classes, etc...
• another assembly which contains the repository implementations.
• a set of infrastructure assemblies:
  • a general 'framework' dll which contains utils that I can use in my presentation, in my domain classes, etc...
  • a dll which contains helpers for DB access (in my case, a thin wrapper around NHibernate).

In contrary to what Nathan Hughes says, I think it is perfectly OK that your presentation layer has access to the infrastructure, as I sometimes omit an 'application service layer'. In such case, my presentation layer is my application. I use NHibernate as well, and for me, it is ok that my presentation layer accesses the NHibernate helpers. Since, my application (which is my presentation layer in some cases), is the only 'thing' that has knowledge of the context of the application. So that's the one who'se responsible for starting and committing transactions for instance.

(As Evans says -in chapter 5 I think: Context is King).