domain-driven design (ddd) vs Domain-Driven Design (DDD)
Practically everybody is doing domain-driven design in some form. When we build new products and services, we’re identifying unmet needs in a particular domain, and then building tools, with models in software, that help people to achieve their unmet needs.
It was before my time, but my understanding is that reason Eric Evans wrote the Domain-Driven Design (DDD) book in the early 2000s was to encourage better domain-driven design (ddd) practices in that era. Design was driven by data models and collaboration between technology and business colleagues was inadequate.
This article reflects my personal understanding of the relevant topics. I am not an authority on these subjects.
The DDD book reflects Eric’s perspective and opinions at that time of how he could move the world of software development to be more domain-driven and less data-model-driven. He uses names like Bounded Context, Ubiquitous Language, and Aggregate to really emphasise these beliefs. These are part of DDD and not ddd (in my opinion).
Evans’ masterpiece is timeless. It has been one of the most influential books that I’ve read, and equally Evans is a role model who I hold in the highest possible regards for his contributions and a person.I still continue to draw new insights and lessons from it that are relevant to how we build products today.
Whether your goal is to get better at ddd or DDD, you should definitely read the book. In particular, the stories of Evans doing ddd, and how he thinks are epic.
I’ve seen people in the wild referring to DDD as Classical DDD or Evans DDD.
What is domain-driven design (ddd)?
I think that Mathias Verraes’ definition of DDD contains a good starting point for thinking about what ddd is:
DDD is a [software] design discipline where you
- Grasp the domain
- Agree on a language
- Express it in shared models
- Embrace complexity
- Separate models in contexts… and evolve them continuously
If you think about it, this applies to almost any software development project. We’re all doing all of these things to varying levels. Just like writing unit tests is a skill, ddd is also a skill that we should work on and try to get better at.
I would personally define ddd as:
- Identifying unmet user needs in a domain
- Gaining expertise in the domain
- Designing new capabilities to address the unmet needs
- Creating specialised models for each part of the new capabilities
- Establishing a specialized language for each model based on domain terminology
- Implementing the model in code
There are a couple of big opinions that DDD brings which I don’t consider to be inherent to all ddd: collaboration and evolution. Collaborative discovery and modelling is at the very core of DDD, involving both domain experts and technology experts.
Evolution is also emphasised strongly in DDD. Good modellers are continuously seeking to improve domain knowledge and improve their domain models. DDD is also pragmatic, advising to only apply heavy ddd where there is a business benefit (e.g. in (DDD) Core Domains).
You can do ddd without collaboration, evolution, and focusing on strategic areas. But unless you are working alone, it’s not going to be effective.
Mathias also adds another excellent point about levels of scale in ddd and DDD:
It considers design from the micro-level of code and design patterns, to models and their language, to communication and relationships between models, to the large scale reasoning about systems of systems.
What Does This Mean in Practice?
Firstly, I don’t think DDD should be split from ddd or abandoned in any way. It’s an excellent toolkit for beginners, providing guidelines and building blocks for getting started with ddd, and helping to develop the ddd mindset. I also think DDD is a fine choice for experienced teams who want to embrace it.
I do think, however, that we should be able to talk about ddd without implying DDD. We can talk about “doing ddd” without needing to use words like Bounded Context, Ubiquitous Language, and Aggregate.
Going further, I think there should be space for other opinionated ddd philosophies to exist alongside DDD, such as Uber’s domain-oriented microservices.
I believe that the DDD Community should embrace all forms of ddd. We can respect the traditions of DDD while still allowing radical new ideas and being inclusive of people who aren’t familiar with DDD. To be fair, the DDD/ddd community is already awesome and doing these things.
