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 not only to know this anti-pattern, but also think about why systems end up implementing it. Note how surprisingly easy 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. 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 task. 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. 
• Let's assume a somewhat better alternative is chosen: moving the domain model to its 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 created. 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 in doing that, sacrifices are made on domain model.

The main problem was caused be the violation of the dependency inversion principle. This can be properly solved by the dependency inversion pattern:

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

There may be valid reasons for anemic domain models too. In the context of tackling high-complexity problems with DDD though, the 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.