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.
