DDD Misconceptions

I have seen numerous implementations of DDD over the years, and during that time, I have noticed a few recurring misconceptions. Addressing these misconceptions helps teams realise the true benefits of DDD, delivering software more aligned with business goals.

Tactical Patterns Alone = DDD

Domain-Driven Design isn’t just a collection of tactical patterns—it’s being driven by domain insight and strategic patterns. Simply using Aggregates, Value Objects, or Repositories doesn’t mean you are “doing DDD.” As Eric Evans reflected, if he were to write the book today, he’d open with strategic patterns instead of tactical ones. Those high-level patterns are the essence of DDD: they prioritise the business domain and bridge the gap between domain experts and developers.

Strategic DDD helps this alignment by:

• Partitioning the Problem Space into (Sub)domains to manage complexity and align with business structure.
• Categorising the Subdomains into Core (differentiating), Supporting (important but non‑differentiating), and Generic (commodity) areas.
• Defining Bounded Contexts to isolate models and ensure precision, clarity and consistency of the language.
• Contexts Mapping to describe how they integrate from a technical and organisational perspective (e.g., partnerships, customer–supplier relationships, anti‑corruption layers, separate ways).
• Prioritising Investments so that you can make informed decisions on where to focus your efforts - more on Core domains than Supporting or Generic.
• Fostering a Ubiquitous Language within each context to keep communication clear and unambiguous.
• Evolving Continuously by revisiting boundaries and integrations as business needs change.

It gives you a strategic roadmap for where and how to apply DDD’s tactical patterns in the most business‑impactful way.

Domain Knowledge is via Proxies

DDD emphasises fostering a shared understanding of the business problem the team is trying to solve. It promotes the removal of information proxies and encourages all stakeholders to communicate and collaborate in modelling and exploring the domain together.

It's developers' (mis)understanding, not domain experts' knowledge, that gets released in production.
- Alberto Brandolini

It is common in organisations to have developers so far removed from the problem that they rely on third, fourth, or even fifth-hand information that barely resembles the original need. They then interpret this information in their own way, adding their own assumptions and misunderstandings before delivering it to the customers. It is akin to a game of Chinese whispers.

DDD pushes all stakeholders to work collaboratively to understand the problem and develop a shared language that describes it, ensuring that nothing is lost in translation. The problem is understood by everyone involved, and there is a shared ownership of that problem.

Promoting group discussions and "together" learning or collaborative modelling is an essential step in distilling domain knowledge and forming a precise ubiquitous language to describe it.

Coherence in concepts and terminology emerges through group learning sessions (a shared experience).
- Matthew Skelton

Ubiquitous Language is Simply The Domain Experts' Language

The ubiquitous language is not the domain expert's language verbatim. It's a shared language agreed to by developers, domain experts, QAs and other stakeholders to communicate about the domain. It provides a common ground for understanding and modelling the software, allowing for clear and unambiguous communication about the domain concepts.

The domain expert's mental model needs to be extracted and understood. It should form the basis of the shared, precise and consistent ubiquitous language, not dictate it. Code does not deal with ambiguity well, and hence, the precision of the language is essential.

Ultimately, there should be alignment between our understanding and the code. The code may be slightly different as it adheres to the underlying intricacies of the chosen programming language, but the conceptual alignment remains intact.

DDD is Dogmatic

Teams adopting DDD religiously follow the DDD concepts without deviation, even when those concepts do not fit the problem they are trying to solve.

I have seen implementations where teams manufacture Aggregates, thinking that there must be at least one because, well, "DDD"! The same applies to other tactical patterns, including Entities, Value Objects, Services, Factories, Repositories, and so on. You do not need to add all of these to be doing DDD. Only use the ones that help you solve the problem, and if none of them do, don't use any. For instance, implementing a simple supporting subdomain as a CRUD service is perfectly fine.

This also extends to strategic patterns. Context Maps is a good example of this. If the defined sets of options do not describe the relationship between your bounded contexts, extend those definitions with your own as long as they better capture and define your unique context.

Remember, DDD is a set of guidelines, not rigid rules—apply concepts selectively, guided by your domain’s real needs.

Domain Knowledge Only Comes From Domain Experts

The real domain experts are sometimes the developers who have been maintaining/testing the code and possess a deep understanding of the problem, how it's implemented, how it has evolved, and why, as well as edge cases.

Even the code you’re actively writing is a rich source of domain knowledge. It helps surface hidden concepts or misunderstandings that are not clear from talking to business domain experts. Writing code helps challenge half-baked concepts as you struggle to crowbar them in, and they feel awkward and out of place.

Sometimes, these implementations are awkward because the model hides competing concerns: parts of the domain that remain obscure because they exist to satisfy the needs of other domain experts. In practice, these latent concepts either belong to a separate bounded context or sit within the same context but address related concerns belonging to a different group of stakeholders.

Brian Marick recounts the story of a troublesome method that repeatedly broke their system in this blog post. To better understand the method, they extracted it into its own object and gave it a domain-friendly name. This new abstraction sped up subsequent feature work—new functionality “fell into place” against the refactored model. Yet when they demoed it to traders (the domain experts), the name made no sense. It turned out that concept was driven by governmental tax-reporting requirements, not the traders’ concerns, so their abstraction never resonated with the people who used it. But it was still valuable domain knowledge for an undiscovered context fighting to emerge.

In essence, domain knowledge emerges iteratively from both domain experts and practical experiences with code; recognising when hidden domain concerns surface is crucial for accurate models.

Conclusion

Misconceptions about Domain-Driven Design are common, yet addressing them is vital for realising DDD's true potential. Recognising that DDD is fundamentally about tackling business complexities rather than tactical patterns helps teams unlock DDD's full potential. The collaborative development of a clear and precise, ubiquitous language—grounded in shared understanding but not simply copied from domain experts—forms the cornerstone of effective domain modelling.

Moreover, adopting DDD pragmatically, rather than dogmatically, ensures your solutions remain flexible, relevant, and genuinely useful. Remember, domain knowledge emerges iteratively from ongoing conversations, the existing system, and experiences gained through code, not exclusively from domain experts.

By dispelling these common misconceptions, you can deliver software solutions that are simpler, better aligned with business reality, and poised for sustainable growth and evolution.