Domain-Driven Design the Wrong Way

| by Jan Stenberg Follow 15 Followers on Apr 26, 2015. Estimated reading time: 1 minute |

A note to our readers: As per your request we have developed a set of features that allow you to reduce the noise, while not losing sight of anything that is important. Get email and web notifications by choosing the topics you are interested in.

Too often applications claimed to have been built using Domain-Driven Design (DDD) and having a domain model in reality only consists of entities or even DTOs separating data and logic together with services containing a mix of business and infrastructure logic, Gabriel Schenker states sharing his experiences from working as a consultant and software architect. In applications with message handling, messages seldom are named from the domain, instead generic names ending with e.g. update or modify are used.

Schenker, currently working as a principal software architect, notes that is not an overstatement only applying to old applications, he often find projects building new applications in this state early on. One of the major reasons for this, Schenker believes, is lack of knowledge.

When working with DDD Schenker emphasizes that not all of the patterns in Eric Evan’s original DDD book is equally important and especially notes that the foundation of DDD is found in the later part of the book, something that has been acknowledged by Evans. In contrast to these strategic patterns the first half focuses on implementation details, tactical patterns.

Schenker’s advice when starting a new project using DDD is to first work with the domain experts to get an understanding of the business domain and from these discussions extract the terminology used to create a common vocabulary that all agree on, a ubiquitous language in DDD terms. Following this a complex domain should be broken up by using the domain experts to identify areas that can be separated from each other, creating sub-domains or bounded contexts, another DDD term.

One thing Schenker warns against is creating a data-centric world starting with a data model. He firmly believes that data in isolation is nothing; logic is required for data to be meaningful, but also notes that this varies with context, thus context and logic should be primary focus doing DDD. Another risk for him when focusing on data is that databases end up being used for integration, effectively creating dependencies between contexts otherwise isolated. Using a common data model was recently also advised against by Stefan Tilkov.

Rate this Article

Adoption Stage

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

Follow-up by Jan Stenberg

In a follow-up post Schenker shows how DDD can be applied, in a realistic context.

DDD while doing structured design? by Augusto Rodriguez

I've never heard anyone claiming to do DDD using a structured approach (even if they were working in an OO language such as Java). I do wonder which dens the author of those blogs consulted for.

There's a bit of a fallacy in the suggestion about data-centric applications. It's absolutely fine to start with a data model (especially if you start with a legacy database), and this shouldn't affect at all the domain design. That's why the Repository pattern exist, to abstract how Aggregates are retrieved/updated/saved/deleted.

The opposite approach is as bad... start with a domain model and hammer that to the Database (relational).

Those two domains (application and data at rest) are different and require good abstractions between themselves.

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 your favorite topics and editors

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


More signal, less noise

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


Stay up-to-date

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