Bounded Contexts 101

I say it again and again to anyone who will listen: modularity is the most important quality you need to focus on to ensure your systems can evolve over the long term. And, fortunately, it’s primarily a business issue, one that CEOs have control over, and one they must address, since it’s so closely tied to the company’s core business!

Modularizing an IT system means defining the boundaries of its Bounded Contexts, a central concept in Domain-Driven Design. For some reason I don’t understand, this concept remains abstract to many of us, so much so that it can be intimidating. That’s a shame, because with practice, you’ll see that it’s not that complicated.

Intuition: a house and a basement

Take the example of a house with a basement: if you go down to the basement too often, say every day, it’s a sign that there’s something there that shouldn’t be (1). Why? Because there’s the living space on one hand, and the storage space on the other. This means we have two contexts defined by how often we access objects: “hot” and “cold.”

This example, as simple as it is, still conveys two important points:

If two contexts chat a lot (“chatty services”), it’s probably because their responsibilities are poorly distributed (a responsibility should be transferred from one to the other), or because they actually constitute a single context.
Modularization minimizes large-scale interactions, but doesn’t eliminate them: contexts must still communicate with one another. Otherwise, it wouldn’t be one system, but several. In other words, you’ll still have to go down to the basement from time to time. It’s a simple truth that we sometimes lose sight of, and one that explains many of the difficulties we face when modularizing.

The whole point of strategic Domain-Driven Design is to break down a large system into subsystems that are as small as possible, the bounded contexts. These are areas of high cohesion and loose coupling with one another, each centered around a single responsibility.

But how, exactly, do you identify the contexts of a given system?

A rough guide to avoiding 2 common mistakes

As a first approximation, a bounded context can be thought of as a business module. The two aren’t strictly identical (the former goes deeper into the breakdown than the latter), but this approximation really helps with understanding.

This analogy is important because it captures the essence of the matter: this division is based on considerations far more closely tied to the business than to technology. Above all, it helps avoid two common mistakes:

Breaking it down into technical layers: for example, “application” and “database.” This division doesn’t hold up, because both serve the same business purpose and constantly interact to achieve it. The physical model derives from the logical model; separating them would make no sense.
Breaking it down into entities: an “invoices” context, for example. As appealing as it may be, this is one of those ideas that sound good but aren’t. To see why, consider that you might want to do very different things with an invoice, starting with issuing it and collecting payment if it’s overdue.

Identifying contexts: think in terms of “action verbs”

Let’s dig a little deeper into the previous example:

Issuing an invoice is a goal in its own right (invoicing), which requires knowing the customer’s company name, the product or service codes and their prices, as well as the applicable VAT rates, contractual terms (invoicing schedule, payment terms, etc.), not to mention a sequence number. Invoicing can be highly specific to a company’s business model and may require extensive customization.
Collecting payment for that same invoice after the due date has passed is a different objective (collection). For those in charge of this activity, it doesn’t matter whether you’re selling barrels of oil or oysters; all that matters is the amount to be collected and the payment delay. Collection isn’t part of the company’s core business, so a third-party tool or service is generally used.

Thus, for the same invoice, there are two distinct purposes, distinct action verbs (invoice and collect), and in fact distinct vocabularies, which define two bounded contexts. A bounded context is an area where a term in the language has a single meaning, according to the definition by Eric Evans, the father of DDD.

There’s much more that could be said on the subject, but these few lines are ultimately quite representative of the reasoning at work when modularizing a system. If you have to remember just one thing: don’t break things down by entity, but by action (what we do with those entities).

This decoupling offers multiple benefits: clarity of the system as a whole (each context operates with relative autonomy), structural isolation and resilience (if your changes cause a regression, there’s less risk that it will spread to other contexts), not to mention that they hand you the definition of your teams on a silver platter (the Inverse Conway Maneuver, where each context is handled by one and only one team).

(1) Put another way, maybe it’s time to bring your girlfriend back up from the basement #NataschaKampusch.