Domain, Subdomain, Bounded Context, Problem/Solution Space in DDD: Clearly Defined
Domain-Driven Design is an approach to designing systems, usually software, that emphasises creating a common language between domain experts and system builders. Famous DDD principles include Use a Ubiquitous Language and Make The Implicit Explicit.
If you like this article, you may like another article I’ve written: What is a Domain?
I would also highly recommend Why I Don’t Need a Bounded Context by Herman Peeren.
However, some concepts in DDD do not have a clear definition and are highly implicit. Everybody has their own definition of Domain, Subdomain, Problem Space and Solution space. In this article, I’m going to provide working definitions of those concepts and clear them up.
It’s also worth keeping in mind that DDD was published in 2004 at a time when empowered, cross-functional product teams were rare. At that time IT was a separate department from “the business”.
This post is based on a long conversation on github involving many people from the DDD community.
Fuzzy But Not Ambiguous
Before defining each term, I want to emphasise an important point that Kenny Baas-Schwegler makes. He argues that DDD should be fuzzy. By having fuzziness in DDD, we can explore, model and solve new and novel problems because the existing patterns and principles don’t over-constrain our thinking.
By fuzzy I mean that a word can be used to describe different things that are similar in some way but not identical. The word “few” is a good example. In some scenarios it might imply a low range like 2 — 3 and in others it could imply a different range like 5–10. In others it can mean £100s of pounds “can you lend me a few quid?”. The key thing is that the fuzziness should be easily inferred from context (if different people interpret it in significantly different ways, that’s too ambiguous).
If I say a word and I expect that you have the same definition, but you actually have a very different definition, we have false alignment. We think we’re talking about the same thing but we’re not.
With DDD, we want to embrace fuzzy, but with shared understanding of how fuzzy each concept can be.
The following definitions are fuzzy, however, we should all be highly-aligned when using these words.
Domains
Domain-Driven Design sticks closely to the Cambridge Dictionary definition of a domain:
an area of interest or an area over which a person has control:
She treated the business as her private domain.
These documents are in the public domain (= available to everybody).
This definition of a domain is very fuzzy. What is an area of interest? It can be anything. A domain is effectively an arbitrary boundary around some subset of concepts in the universe.
Domains are subjective and they are not mutually exclusive. The same concepts can exist in many different domains. Here’s an example I use in talks and workshops:
If the coloured shapes in the image above represent concepts, how would they be grouped into domains? As you can guess, there are a number of ways to do this.
We can group the square shapes into the Squares domain, and the circles in the Circles domain. But the blue square and the blue circle could also belong to the Blue domain.
When modelling systems we have to choose the most appropriate domain boundaries with which to align our software and organisational boundaries. Even if we align we align by ‘colour’ the shape domain is still a domain that exists.
Every domain I model and every modelling workshop I run, different people like to slice up systems across different domain boundaries. This is normal, embrace the fuzziness and apply design thinking.
Subdomains
What’s the difference between a domain and a subdomain? This one is easy — subdomain is not a word that exists in the dictionary. The word subdomain is used prominently in the world of web hosting, but what does it mean in DDD?
In DDD, a subdomain is a relative term. Domain and subdomain can be used interchangeably. When we use the word subdomain, we are emphasising that the domain we are talking about is a child of another higher-level domain which we have identified.
Every subdomain is, therefore, a domain, and most domains are a subdomain. The only time I wouldn’t say a domain is also a subdomain is when our model does not contain a higher-level parent domain.
Core, Generic, Supporting (Sub)Domains
People are often confused when they hear that a core domain is actually a subdomain. In his DDD books, Eric Evans refers to them as Core Domains, but he also refers to them as subdomains. Confusing much?
When you view domains and subdomains as fuzzy, and subdomains also as domains, using core domain and core subdomain interchangeably doesn’t really matter. It’s fuzzy but not ambiguous.
Core Domain sounds better, Core Subdomain emphasises that there is a higher-level domain to which this belongs.
Subdomains vs Bounded Contexts
Perhaps the most confusing and controversial topic of all is subdomains vs bounded contexts. Two types of boundaries.
Some people suggest that subdomains are part of the problem space an chosen by “The Business” whereas bounded contexts are software boundaries defined engineers.
To me this has a very antiquated feel about it. And it makes sense. DDD was published 20 years ago, at a time when there was a split between the business and the separate IT department. There was a big gap between business boundaries and software boundaries.
But in modern, product-led organizations, this no longer makes sense. IT is embedded in “the business”. There is no separate IT team. Empowered engineering teams own the products they are building, and they shape their own team topologies. The business, organizational, domain, and software boundaries are all defined by the same people.
Problem Space vs Solution Space: Proposing a Better Model For DDD
The most confusing terms are problem space and solution space. Everybody has a different view on what lives in the problem space and what lives in the solution space in the context of Domain-Driven Design.
I think the problem/solution space model is too simplified for what DDD is trying to express. It is too ambiguous and more precision is needed. The elements in Simon Wardley’s Strategy cycle are much more usable in my opinion.
In Wardley’s Strategy Cycle, there are the following elements (with my simplified definitions):
- Purpose: what is the problem being solved / goal to be achieved in our domain(s) of interest?
- Landscape: what is the current state of the domain(s) we are interested in
- Climate: what forces are acting on the domain(s) and how are they likely to evolve
- Doctrine: universally good practices we should apply
- Leadership: what is our solution… what changes are we going to make in existing and new domain(s)
Are Domains/Subdomains Problem or Solution Space?
This question can’t really be answered unless we have a clear definition of problem or solution space. But I’ll have a go anyway.
Do you really know what problem space and subdomain are or do you just know the name?
User needs and problems exist in a (sub)domain(s), the current state of the world has (sub)domains, the solution will involve multiple (sub)domains and it will alter the state of the world (which has domains). Therefore, (sub)domains logically exist in all spaces.
How can a subdomain only exist in the problem space when the design determines which subdomains we need to build solutions in? Ergo, some domains are only relevant to the solution and not the problem.
New solutions create new problems, or in the words of Simon Wardley Higher Order Systems Create New Sources of Worth.
I still recommend avoid using problem/space and instead be more specific about what you actually mean: purpose, landscape, climate, doctrine, leadership, or something else.
Whenever using the terms problem space and solution space, you need to clarify from which perspective you are speaking. Your problem space is someone else’s solution space. It’s your view of the domain.
Domains are Hierarchical
If a domain can contain subdomains, and a subdomain is a domain… then a subdomain can contain more fine-grained subdomains. Domains and subdomains are a hierarchical concept.
When designing socio-technical systems, we often want to show domains at different levels. Leadership of an organisation might want to see the companies 7 top-level domains. Software architects might want to see the domain boundaries for 100 microservices.
The Enterprise Architecture world uses the concept of Business Capabilities at different levels. Business Capabilities can be viewed as domains and subdomains.
Subdomain vs Bounded Context
This is one of the most confusing things about DDD, but when you have a clear definition of subdomain it’s actually the simplest to explain.
I’ve already established that a (sub)domain is a non-mutually-exclusive, arbitrary subset of concepts in the universe. A bounded context is the boundary of a model that represents those concepts, their relationships, and their rules. The same subdomain could be represented by an infinite number of modelling choices.
A model in DDD can be represented in a variety of formats such as post-it notes or code. Anything that shows domain concepts, relationships, rules, and so on.
Since a bounded context is a boundary for a model, it could include concepts from multiple subdomains. Or a single subdomain could be modelled as multiple bounded contexts.
Agree or Disagree?
Do you agree with these definitions, and are you happy to use them going forward? If not, please leave a comment. I care more about creating a shared understanding in the DDD community than pushing my definitions as the de facto standards. I’m very happy to change my mind…
