Domain Development

Question

The layer scheme for DDD assumes that the layers must be:

Presentation / Application / Domain / Infrastructure

The diagram presented in Evans' book shows Presentation, access to infrastructure level. Is my interpretation of this diagram correct, since any of the upper layers can be allowed access to any of the lower layers?

Answer 1

This question was asked using the word “layer”, so my original answer was about layers. It is probably best to start by saying that DDD is not about hard layers, but about creating an application in a way that is easy to verify and change, since it encourages the separation of problems between different objects.

I do not like to call a domain a “layer” because domain objects do not actually form a layer in the usual sense, they are transferred between layers, but do not belong to any of them. Regarding the availability of the level of presentation of access to infrastructure, the diagram says that this is an option. It is up to you how abstract access to the infrastructure is from the presentation. In most cases, I would like to go through the application level so as not to associate it with the implementation details, but a direct approach is an option, the decision is up to you.

I think this is a little frustrating for reading Evans' book due to the lack of concrete examples, but he is trying to make it widely applicable, and some languages ​​are much more flexible than others so that they can do something different. For example, when using Java and Hibernate, I don’t have links from the domain to data access objects, I’m thinking of implementing persistent sets of Hibernate that serve as repositories that allow lazy traversal of the domain model. But the decision to implement, based on my choice of language and libraries, and other situations can justify various decisions.

Answer 2

Hmm, IMHO DDD is not so much a "bundle." This is more about modeling the problem you are trying to solve in good shape, so your model (objects, value objects, repositories, services, specifications) reflect the real problem area.

However, there really is some kind of “separation” between the classes you write, but I really haven’t gone as far as calling it “separation”, since IMHO is great for your presentation classes and domain classes such as infrastructure. However, domain classes should not be dependent on presentation classes, for example, but the opposite may be true.

I mainly organize my projects this way:

• a has an assembly containing material associated with the view. (Forms, etc.)
• I have an assembly that contains a "domain". This includes objects, interfaces, specification classes, etc.
• another assembly that contains repository implementations.
• set of infrastructure assemblies:
  • a generic 'framework' dll that contains utils that I can use in my presentation, in my domain classes, etc.
  • a dll that contains helpers for accessing the database (in my case, a thin shell around NHibernate).

Unlike what Nathan Hughes says, I think it’s normal that your presentation level has access to the infrastructure, as I sometimes omit the “application service level”. In this case, my presentation level is my application. I also use NHibernate, and it is normal for me that my level of presentation appeals to NHibernate helpers. Since my application (in some cases this is my presentation level) is the only "thing" that has knowledge of the application context. So the one who is responsible for starting and completing transactions, for example.

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