Domain-driven-design (DDD) pitfalls

Question

I am quite new with DDD and would like to know about any pitfalls you might want to share. I will summarize it later for more newbies to read :)

Thanks

Summary s

Answer 1

Probably the most important one: not grokking the central, fundamental principle of the Domain Model and its representation in Ubiquitous Language. With the plethora of technology options around, it's very easy for your head to fill up with ORMs, MVC frameworks, ajax, sql vs nosql, ... So much so there's little space left for the actual problem you're trying to solve.

And that's DDD's key message: don't. Instead, explicitly focus on the problem space first and foremost. Build a domain model shorn of architectural clutter that captures, exposes and communicates the domain.

Oh, and another one: thinking you need Domain Services for everything you can do in the domain model. No. You should always first try to put domain logic with the Entity/Value type it belongs to. You should only create domain services when you find functions that don't naturally belong with an E/V. Otherwise you end up with the anaemic domain model highlighted elsewhere.

hth.

Answer 2

You might enjoy presentation of Greg Young about why DDD fails.

In short:

• Lack of intent
• Anemic Domain Model
• DDD-Lite
• Lack of isolation
• Ubiquitous what?
• Lack of refinement
• Proxy Domain Expert (Business analyst)

Answer 3

Only adding to what others have already said; My personal experience is that people often end up with an anemic model and a single model instead of multiple context specific models.

Another problem is that many focus more on the infrastructure and patterns used in DDD. Just because you have entities and repositoriesand are using (n)Hibernate it doesn't mean you are doing DDD.

Answer 4

Beware of the Big Ball of Mud.

One of the pitfalls of domain driven design is to introduce ambiguity into a model. As explained in the article Strategic Domain Driven Design with Context Mapping:

Ambiguity is the super-villain of our Ubiquitous Language

This may happen when two distinct concepts share the same name, or when the same concept can have different uses. It may be necessary to

expose the domain structure in terms of bounded contexts in a context map

If a model is used in too many different ways, or has too many responsibilities, it may be a sign that it should be divided.

Answer 5

Not using bounded contexts enough. It's toward the back of the the big blue book but Eric Evans has gone on record as saying that he believes that bounded contexts and ubiquitous language are THE most important concepts.

Similarly, people tend to focus too much on the patterns. Those aren't the meat of DDD.

Also, if you do not have a lot of access to domain experts you are probably not doing DDD, at best you are DDDish.

More concretely, if you end up with many-to-many relationships, you've probably designed something wrong and need to re-evaluate your aggregate roots/contexts

Answer 6

It's not from my personal experience with subject, but it was mentioned for a couple of times in DDD books and it's what I've been thinking about recently: use Entities when you really need identity, in other cases use Value Object. I.e., Entity pattern often happens to be the default choice for any model noun, and it's not the way it should be.