DDD Anti-patterns: 5 things we get wrong with Domain Driven Design in practice

As a software architect I have been using various design techniques including Domain Driven Design (DDD) which has been incredibly useful for building APIs and Microservices and for strategic architecture consulting engagements requiring discovery/mapping of socio-technical organisation structure and in documenting an API strategy

I have also been training architects across organisations to understand and apply DDD which has led me to some interesting observations especially around things that do now work when learning or applying this technique

Here are some common DDD anti-patterns

1. Not including domain experts: Domain discovery in DDD is done by interviewing domain experts and capturing their stories. My observation has been that often Technical SMEs (SME= Subject Matter Expert) tell the stories for the domain experts with little to no consultation with a Business SME. This anti-pattern leads to a false picture of the domains and boundaries, which can lead to wasted effort
2. Building an anemic domain model: One of the common practices I have seen with tactical domain modelling is models without domain logic or models with externalised logic. This is especially true when we build domain services with integration products like a Mulesoft or Boomi while delegating the details to a backend (Another database, Salesforce, Guidewire etc). This ant-pattern leads to a communication overhead and creates atleast 2 copies of the model (one is a fascade and the other is the actual implementation) leading to other issues down the line
3. Leaving out Strategic modelling when doing DDD: When I poll teams around what they know about DDD there is familiarity and some expertise in tactical DDD and the language teams use are around “The Code is the Model”, “Ubiquitous Language”, “Aggregates”, “Entities”, “Repositories” etc. It is RARE to hear someone talk about how powerful Context Mapping is in documenting coupling between teams and how they were able to show their monolith is a “shared kernel” pattern etc. My opinion is that strategic DDD is the awesome sauce in domain driven design especially for tech strategy and enterprise business architecture – yet many architects are not aware or do not use this technique often
4. Doing DDD for the sake of DDD: Do DDD for a business outcome and not just to learn a design technique. We are all guilty of resume driven work which for architects can translate to doing DDD because it is a great design technique and I want to learn it! This is an anti-pattern because the work stops when we have a context map or a model without realising the value for the business. I would love to see more of this technique applied to drive an outcome with stories like “we applied strategic modelling to discover shared kernels and collaboration across context through context mapping and then applied tactical DDD to model the domains and build services so that teams collaborate across boundaries using as-a-service model’
5. Limiting to internal contexts only: This is a hard one but we are often guilty of only looking inwards and not around the entire ecosystem. For example, when we work with domain experts to document language and find boundaries etc for context mapping one trend I see that been to describe internal contexts only. This completely misses what the world around us is doing, the contexts in which they are doing, why they do what they do with our business etc leading to interesting conversations around our product and how we express it as technical capabilities. With this anti-pattern we missing key aspects of why and who we serve as a business they our customer/partner contexts

Summary

In summary, when doing domain driven design we tend to focus on the tactical aspects or for the strategic DDD we focus less on the “so what” and “for whom”. I believe re-defining what the entire picture looks like is the key here – it is just your internal contexts or would you consider other contexts too and include domain experts from partners, experts from customer research or even customers to understand why and how they collaborate with you & your software