BT

10 Common DDD Mistakes to Avoid

| by Jan Stenberg Follow 34 Followers on Jul 12, 2015. Estimated reading time: 2 minutes |

Not interacting with domain experts is one of a common set of mistakes done when using Domain-Driven Design (DDD), finding and correcting them early on may save a team time, Daniel Whittaker claims describing ten mistakes he regularly see developers do.

Allowing persistence or data storage to have an impact on a model. Tactical patterns, e.g. aggregate roots, simplify models and isolate them from infrastructure concerns like data storage. Starting with schemas or data modelling instead of talking with domain experts may create code based on a relational model instead of built around a domain model. On a similar subject Stefan Tilkov earlier warned about using a canonical data model within an enterprise because of the optional attributes and strange behaviour such a model will end up with.

Not engaging with domain experts. Talking to domain experts to get an understanding of the problem domain from their perspective is at the core of DDD. Behaviour-Driven Development (BDD) emphasizes conversation with domain experts creating examples of the behaviour and earlier Konstantin Kudryashov talked about bringing BDD and DDD practices together.

Ignoring the language of the domain experts. Creating a ubiquitous language shared with domain experts is also a core DDD practise. This common language must be used in all discussions as well as in the code, e.g. in class and method names.

Not identifying bounded contexts. A common approach to solving a complex problem is breaking it down into smaller parts. Creating bounded contexts is breaking down a large domain into smaller ones each handling one cohesive part of the domain. It is also a key concept in microservices, something Eric Evans talked about in his keynote at this year’s DDD Exchange conference.

Using an anaemic domain model. This is common sign that a team is not doing DDD and often a symptom of a failure in the modelling process. At first an anaemic domain model often looks like a real domain model with correct names etc. but the classes are lacking almost all behaviour, instead just being containers with getters and setter for properties.

The five remaining mistakes Whittaker have recognized are:

  • Keeping bounded contexts despite deeper domain insights.
  • Assuming all logic is domain logic.
  • Overusing integration tests.
  • Treating security as part of the domain (unless working in a security domain).
  • Focusing on infrastructure.

A final mistake Whittaker mentions is not looking into Event Storming, a design process focusing on events, created by Alberto Brandolini. By gathering all key stakeholders in a room with unlimited modelling space and using stickers as domain events, Brandolini claims they may in hours create a very good model of a problem domain.

Rate this Article

Adoption Stage
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Nice experience by Marius Matei

A very interesting summary of the mistakes that we can make in designing our modern projects. I always thought that we have to make these mistakes in order to understand the core of DDD. We experienced a lot of anaemic models in our recent projects development. The wrong use of frameworks like Spring and of the MVC pattern have encouraged such models. I think that the most important issue in applying DDD principles remains "Ignoring the Language of the Domain Experts" as it hides other organisation problems.

Re: Nice experience by Daniel Whittaker

Good point - you need to experience the pain of making them to get 'why' they are a mistake.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

2 Discuss

Login to InfoQ to interact with what matters most to you.


Recover your password...

Follow

Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.

Like

More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.

Notifications

Stay up-to-date

Set up your notifications and don't miss out on content that matters to you

BT