A common pitfall of Domain-Driven Design

The philosophy of domain-driven design - placing the primary focus on the core domain - is a very natural and powerful concept for application design. Despite the core idea being simple, the learning curve is apparently steep. DDD is very often implemented wrongly, an unideal architectural decision can lose the potential of obtaining and taking advantage of a rich domain model.

There is a specific pattern I've come across surprisingly often in systems built on the notion of DDD. I think it's useful to know about this anti-pattern, and why/how systems end up implementing it. It is to navigate a design to wrong directions.

Given some domain, the development starts with a single layer including some prototype of a domain model. Then the need for some infrastructure comes into picture - most commonly some sort of persistence solution. That's placed into another layer with the good intention of keeping responsibilities separate.
The result is this:

This won't work well, there is a problem with the dependency. The domain model depends on the infrastructure layer to do its job. The infrastructure layer can't access the domain objects - to persist them for instance - due to the direction of the dependency. There are many ways to solve this:

• Pushing part of the model to the infrastructure layer. Responsibility leak, something to be avoided.
• Transfer objects defined in the infrastructure layer. The domain will still be concerned with infrastructure specifics. 
• Lets assume a somewhat better alternative is chosen: moving the domain model to it's own layer:

The infrastructure trouble is solved and layer design of many applications stops at this point. In my experience it is a really common pattern. It looks like the real deal with the domain model having a dedicated layer. So let's take a look at the issues:

The domain model can't access the infrastructure layer. As a result, parts of the domain model that rely on infrastructure - actually most of it - will have to be moved up to the application service layer. Gradually - to keep things consistent, symmetrical - most logic will be moved out from the domain layer, leaving mere property bags behind with little or no logic. The end result of all the efforts is the classic case of an anemic domain model:

 
Where did things go wrong? As it turns out, at the very beginning, when the infrastructure layer was introduced. In DDD the domain model is supposed to have the main focus, yet it was made dependent of a layer with infrastructural responsibilities. Subsequent efforts try to address this and while it succeeds on the surface level, sacrifices are made on domain model.

The main problem was caused be the violation of the dependency inversion principle: a higher level module (domain) should not be dependent on a lower level one (infrastructure). This problem can be properly solved by the dependency inversion pattern:

This simple change makes a world of difference: obstructions are out of the way of building a rich domain model, implementing all the domain functionality. Other layers become thin - no domain logic in them - and can concentrate on their own resonsibilities (eg application services or infrastructure integration details).

In the context of tackling high-complexity problems with DDD, this pattern described above is definitely something to look out for. It's very easy to compromise a domain model with constraints imposed by fundamental layering issues.