Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News 10 Common DDD Mistakes to Avoid

10 Common DDD Mistakes to Avoid

Leia em Português

This item in japanese


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


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.

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

Community comments

  • Nice experience

    by Marius Matei,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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

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