DDD Confusion: Bounded Subdomain Context Module, or What?
In my work as a trainer for domain-driven design (short: DDD), I notice that participants of my DDD training courses occasionally have trouble distinguishing precisely between five terms:
- bounded context
Subdomains are confused with bounded contexts, or the term module is used as a synonym for subdomain and bounded context. Out there on the web, such mistakes often happen as well.
Yes, these things really have a lot to do with each other, but they are just not the same! And it is important to keep them apart so that everyone on the team (domain experts and developers) knows what is being talked about. Let’s just do that “in between” in this article.
Domains and models
A domain is a field of knowledge and influence, and its problems are to be solved by our software. Trade, banking, telecommunications – these are extremely large domains. The idea is to make them understandable and manageable in conversations by dividing them into subdomains. For example, banking could be divided into the subdomains of saving, investing, lending, payment transactions, and many others. “Investing” can be divided again into subdomains such as trading in stocks, precious metals, or real estate.
A domain model is an abstraction, a simplified image of a domain or subdomain. This simplified image, reduced to the essentials, is created so that it is easier to talk about it with several people, e.g., the domain expert, users, and developers, without the need of all the details each time. So, all these models are deliberately imprecise and therefore very useful.
Domains and subdomains are “out there” in reality, outside the head of a single observer. Domain models are “inside” the heads, as abstractions, ideas, and concepts. Or they are “inside” the machines as formal models as well, especially as executable code, which is also a model (i.e., a simplified abstraction of reality).
While domains are still relatively easy to understand, the term context is where confusion usually begins. This is because there are several fields in which to apply the word “context”. It can be defined linguistically, or socially, or strictly in relation to domain models.
A linguistic context, for example, is an environment or situation that gives meaning to the words or statements that appear in it. If we take the words “nature”, “forest”, “mountain”, and “lake”, they will have different meanings in the context of biology and in the context of tourism, even though a forest is a forest in both contexts in a sense, because it is a large ecosystem made up of trees.
A social context is the amount of people who use the same word to mean the same thing. In a company I can see that the salespeople talk about a customer in a similar way, just like the support people do among themselves, but they do it quite differently from the salespeople, whilst both use the word “customer”. Therefore, contexts can also be groups of people, here they are “sales” and “support”.
In terms of domain models, we speak of a bounded context, which is the environment or situation in which a domain model is applicable, meaningful, and valid. Examples: a specific team, a specific part of the application, or a specific codebase.
It must be possible to delimit a bounded context, the boundary must be recognizable and describable, otherwise it is not a bounded context. A bounded context provides a framework for a domain model piece. Therefore, it is also “inside” according to the previous section, it is imaginary, not reality.
In my DDD training courses I teach the techniques “Event Storming” and “Context Mapping”, i.e., the drawing of context maps, among others. Linguistic contexts found in the Event Storming become bounded contexts in the context map. These provide an excellent basis for boundaries, which can be used to form powerful, autonomous, agile teams, which means social contexts.
Suddenly it becomes clear how language, modeling, and social matters can and should correlate to create successful development organizations.
Once the term “module” is added as a third term, which is also used in DDD, the confusion is usually perfect. On the one hand, this is again due to the fact that there are different perceptions of modules. On the other hand, there is great similarity between modules and bounded contexts. As for perceptions first: There are conceptual modules, modules in the model, and modules as namespaces.
A conceptual module is a collection of related concepts that can be talked about regardless of other concepts. The concepts within a module should have something to do with each other, and not be a mix of unrelated ideas. Modules should be made in such a way that you can talk about one module without having to talk about the others it is related to. All in all, it should be possible to tell the story of the system with the help of the modules. Example: If a customer orders something and it is not in “stock” at the time, the “purchasing” department has to reorder it. At the time of “goods receipt”, we notify the “shipping” department, which can arrange the subsequent delivery to the customer. Stock, purchasing, goods receipt, and shipping are therefore good module names that can be used to retell the trading process.
A module in the model is used to partition the domain model along high-level domain concepts. Thus, there would probably also be a “purchasing” module in the domain model that deals with purchasing processes.
A module is always also a namespace (or package). The names of things inside the module are only valid together with the name of the module, i.e., not valid outside of it. An item in goods receipt can be something “slightly” different from an item in purchasing. Difficult, isn’t it? But that’s what modules are for, among other things, namely, to form structures in which you still know your way around.
The confusion now mostly arises due to the fact that you can later form bounded contexts from conceptual modules or from subdomains as well. Or you could divide a single bounded context, which is perhaps still too large, into further modules.
Now, at the latest, you have to keep all these things clearly apart so that others still know what you are talking about.
Confusion in 1:1 relationships
DDD users (and participants of my training courses) initially find it particularly difficult to tell these things apart, especially when they occur only once and/or are all called the same.
Example: A domain X with only one bounded context X and a top-level module named X, as well as the bounded context and the domain.
As soon as the problem to be solved becomes too simple, one often no longer knows why and when domains, bounded contexts, or modules are necessary and when to use which one.
In that case: It is better to first model something “moderately difficult”, so that the motivation and the differences become clear, and to later model something very simple, in order to identify the resulting 1:1 special cases as such. In the end, you should model something very difficult and “strike hard” with what you have learned.
So, what do we have now?
- A domain is a field of knowledge and influence, and its problems are to be solved by our software.
- A context is a framework that gives meaning to the things that are in it – linguistically, modeling-wise, or socially.
- A module is a “bag” into which you put something and on which you write a new name in order to be able to talk about it altogether as “one”.
You can use modules to specify subdomains and contexts or to just structure a bit more accurately.
- Evans, Eric (2004), Domain-Driven Design: Tackling Complexity In the Heart of Software. Boston, MA, USA: Addison-Wesley Longman Publishing Co., Inc.
- domainlanguage.com (2016), DDD Reference