DDD Confusion: Bounded Subdomain Context Module, or What?

Verbal confusion

In my work as a trainer for domain-driven design (short: DDD), I notice that partic­i­pants of my DDD training courses occasionally have trouble distin­guishing precisely between five terms:

• domain
• subdomain
• context
• bounded context
• module

Subdo­mains 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 devel­opers) 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, telecom­mu­ni­ca­tions – these are extremely large domains. The idea is to make them under­standable and manageable in conver­sa­tions by dividing them into subdo­mains. For example, banking could be divided into the subdo­mains of saving, investing, lending, payment trans­ac­tions, and many others. “Investing” can be divided again into subdo­mains 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 essen­tials, is created so that it is easier to talk about it with several people, e.g., the domain expert, users, and devel­opers, without the need of all the details each time. So, all these models are delib­er­ately imprecise and therefore very useful.

Domains and subdo­mains are “out there” in reality, outside the head of a single observer. Domain models are “inside” the heads, as abstrac­tions, 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).

Contexts

While domains are still relatively easy to under­stand, 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 linguis­ti­cally, 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 state­ments 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 sales­people talk about a customer in a similar way, just like the support people do among themselves, but they do it quite differ­ently from the sales­people, 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 appli­cation, or a specific codebase.

It must be possible to delimit a bounded context, the boundary must be recog­nizable 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 bound­aries, 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 devel­opment organizations.

Modules

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 percep­tions of modules. On the other hand, there is great similarity between modules and bounded contexts. As for percep­tions 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 subse­quent 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 struc­tures 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 subdo­mains 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 partic­i­pants of my training courses) initially find it partic­u­larly 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 “moder­ately difficult”, so that the motivation and the differ­ences 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.

Summary

So, what do we have now?

TL;DR:

• 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 – linguis­ti­cally, 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 subdo­mains and contexts or to just structure a bit more accurately.

Liter­ature

• 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