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.