Still Causing Conflict: (Sub) Domain vs. Bounded Context I
The most misused terms in DDD are “(sub) domain” and “bounded context”. And this is a big mess because these concepts should be the bridge between business, product and engineering. How can we fix this?
The dilemma with Domain Driven Design (DDD) is that many people think they know what it means, but in fact they only know the words.
But knowing the name of something doesn’t mean you understand it.
In my experience the most misused terms in DDD are “(sub) domain” and “bounded context”. And this is a big mess because these concepts should be the bridge between business, product and engineering.
Failure to clearly understand what they mean leads to conflict between stakeholders, product managers, and developers.
DDDs importance for software projects
These conflicts have an immense impact on the progress and quality of software development. From macro to micro architecture, from package structure to the individual line of code – aligning boundaries creates speed. Combined with short learning cycles, this becomes a critical capability of a product-driven organization.
Valuable alignment is created by discussing real domain challenges and takes time. But if that alignment takes too long or is constantly challenged by misguided thinking, the return on investment won’t pay off.
A perception to take into consideration
“It’s all about slicing for efficiency.”
“(Sub) domain” is a strategic DDD concept that helps to structure the problem into core, supportive, and generic parts. This decision should be linked to the business model and its mechanics. Revealing where to spend more effort meaningfully and where to spend less.
“Bounded context” is a tactical DDD concept that helps group parts that refer to the same aggregates, events, value objects, etc. to avoid solving similar problems multiple times. Ultimately, to reduce the amount of duplicated effort spent on similar problems.
Neither is strictly related to product or engineering alone. And neither is sufficient to decide how to slice a problem. The two are very rarely congruent. This means that simply slicing along the boundaries of “(sub) domains“ or “bounded contexts“ is rarely possible. So it is necessary to take both into account when deciding where to compromise.
There are several types of emails that are sent. On one hand transactional emails around the order and on the other hand newsletters. I would argue that both are in different “(sub) domains“ and in the same “bounded context“. But what do we do with this information?
Do we follow the “(sub) domain“ and implement the functionality in separate systems/modules/components or do we follow the “bounded context“ and keep it in the same system/module/component? Going even further: Is it built by separate teams independently or by the same team?
How do we decide? This is a whole lot of discussion, which we will tackle in part 2 of this series.
The confusion stems from the fact that it is much easier, especially for developers, to reason about “bounded context“ than about “(sub) domain“. “Bounded context“ has clear, very concrete artifacts to recognize and reason about. Whereas the characteristics to reason about “(sub) domain“ are hard to recognize and not clearly defined in DDD.
How can we fix this?
To solve the difficulty of reasoning about and thus separating “(sub) domain“ from “bounded context“, we can look at other tools such as the Business Model Canvas or Wardley Mapping.
The Business Model Canvas consists of holistic building blocks and derived domains that address separate business problems independent of the specific business model. Using these as a blueprint for slices can provide a foundation for thinking.
In Wardley Mapping, the doctrines try to add more principles and a decision matrix to assess whether the problem is core, supportive, or generic. Using a different categorization: Genesis, Custom, Product, and Commodity, with an evolutionary view.
Since there is so much confusion about DDD terms, perhaps it is time to replace DDD’s “(sub)domain“ concept with a more holistic model based on the domains of the Business Model Canvas paired with Wardley Mapping’s Landscape.
