Domain-Driven Design is about Language, not Code

Here’s 5 DDD pitfalls you need to watch out for to avoid getting trapped. It’s easy to get carried away following the blue book. Where I see developers struggle the most is when adopting a framework that should be following DDD principles but isn’t.

This happens the most with ORMs that are using words such as Repository and Entity extensively. It’s easy to avoid these problems by applying a few rules, but applying it to your project is a whole new level of complicated.

Where did we go wrong?

The practical use of DDD is about leverage non-technical business jargon in your code.

Ever had problems naming something?

Tactical DDD is very hard to apply with a positive return of investment without Strategic DDD. I go into detail on the difference in my No-nonsense TDD booklet that relies heavily on DDD to accelerate adoption and modularity.

TL;DR Bullet list - Be wary of

• Non-DDD frameworks that use the words repository, entity, aggregate

• Modelling your entities based on your database tables

• Not having any clear concepts for your aggregates

• Not having enough Value Objects

• Lacking a domain-specific language

Instead, establish a clear domain-specific language. One that both business and your engineering team can agree on.

Incorporate important domain concepts to interfaces, adapt them with your frameworks and tools, not the other way around.

Remember, DDD is not about your code.

The books only get you so far, the real benefit is coming from business collaboration. Please, interview your product owners, sales people and customer success experts. Adopt their jargon. Codify it.

It’s about getting merging business understanding and engineering prowess in a single mind.