DDD Strategic Patterns: How to Define Bounded Contexts

DDD owns the concepts of Core Domain, Generic Domain, and Bounded Context. Let's discuss what they are, how to define them, and whether there is any connection with business capabilities.

Domain

A domain is the reality we inhabit: its entities, their behavior, and the laws they obey. It existed before us and will exist after us, in one form or another. Its existence doesn’t depend on our awareness. Marketers come up with new features and perform market analysis, key account managers communicate with clients, software developers automate business-processes. That’s why the domain is called a Problem space.

Subdomains

DDD implies domain decomposing into subdomains, to ease their modeling and comprehension.
The very fact that you run a business infers that there is at least one predominant business value. The one you earn money with. The one we started out our business for. So even if you do not know such a word like “Core domain”, it is still present. The same applies to sub-domains: probably you gonna need a bookkeeping, human resources, technical support — but it is secondary.

Domain Model

There is no need for modeling extracted sub-domains in their entirety. There is a certain set of rules in each subdomain that we are interested in. For example, if an online shop wants to implement financial reconciliation with payment system, there is no need in modeling all existing rules of Accounting or Financial Control. All that the shop is interested in during reconciliation is to make sure that it and a payment system processed their payments the same way: that all payments considered successful by shop are considered successful by payment system. Say, a payment system successfully processed a payment which was considered non-successful by a shop. It means that the client was charged, but its order is not going to be delivered. So a shop wants to recognize such cases as soon as possible.

It doesn’t look like an Economics course — it’s exactly what the business guys are interested in in current sub-domain. And it’s exactly what needs to be implemented in code. So a rule set in some sub-domain that is necessary to achieve a certain business-result is called a model.

Bounded Contexts

A Bounded Context Is a Logical Boundary

When both subdomains and the core domain are defined, it’s time to implement the code. Bounded context defines tangible boundaries of applicability of some subdomain. It is an area where a certain subdomain makes sense, while the others don’t. It can be a talk, a presentation, a code project with physical boundaries defined by the artifact- bounded context is a pretty vague concept for a lot of developers.

I can come up with three perspectives from which to look at the concept of a bounded context.

From the run-time perspective, a bounded context represents logical boundaries, defined by the contract of a service where the model is implemented. The contract can be represented as this service’s API or a set of events it publishes and consumes. From this perspective, bounded context has nothing to do with physical boundaries. Say, for some technical reasons, we want to distribute our code among several physical machines. It’s likely that we factor out an aggregate that sends HTTP requests to external systems, with an intention to put it into a separate machine which can be scaled independently. The fact that we have a separate machine with some separate codebase doesn’t make it a bounded context. Corresponding code might reflect a part of a model that was distributed among several machines due to technical reasons. It’s just an implementation detail of this model.

From the perspective of a domain expert, bounded context is an area where certain business processes are implemented, a certain ubiquitous language is applied, and certain terms make clear sense, while others don’t. Probably the best way to represent this areas is just to draw some rectangles connected with arrows — more on this later.

For a software developer, i.e. from the static code perspective, a bounded context represents a way one designs models around corresponding subdomains. How many codebases is a specific subdomain implemented with? What concepts do they consist of? Which concepts are applicable in each of them? That’s why it is said that bounded contexts belong to a Solution space.

I like this example of a bounded context concept.

Bounded Contexts Are Aligned Along Subdomains

It seems natural that the code belonging to some bounded context would implement a single subdomain, the one it was intended for, having no clue about the others. Besides that it’s only natural, it’s desirable. After all, we have a problem and we have a solution. We have a subdomain and we have a bounded context. This bijection is how DDD aligns business and IT, domain and software. And this is its main mission.

But Not Always

But this alignment is not always a case, of course. The most frequent reason is some legacy system that was built without a DDD approach in mind. Bounded contexts in such systems can expose several subdomains. What might it look like? A simple example: PSP, as usual. One subdomain represents a transaction processing logic, and the other, transaction reconciliation logic. So the following code represents these two sub-domains within a single bounded context:

class Gateway
{
    public function go()
    {
        $this->processPayment();
        $this->processReconciliation();
    }

    private function processPayment()
    {
        // do some stuff here
    }

    private function processReconciliation()
    {
        // do some stuff here
    }
}

Second, there can be some third-party systems that know nothing about our business and the way we decomposed our domain into subdomains, so such systems might be aligned with our subdomains quite poorly.

But the reason can be even worse: from the very start, bounded contexts were identified incorrectly. Well, first they look OK, but later, some problems arise. It seems like there is more than one global goal, more than one motivation for change. I like these examples. Basically, they illustrate the “Wrong reuse” chapter: decomposing your domain along nouns and putting everything related somehow to that noun into its own context. Cyrille Martraire stresses the importance of extracting bounded contexts based on their responsibilities and behavior. As a result, these contexts most probably would have different evolutionary forces and different motivation for change.

How to Define Subdomains and Bounded Contexts

This is my problem with the notion of sub-domain and bounded context in DDD. It just fails to clearly tell how to identify them. If DDD would explicitly claim that we should define our sub-domains by business capabilities (with relevant examples that don’t include the notorious Product Catalog or Orders bounded contexts), such dichotomies would have no chance to appear. And this is the reason, I guess, why there are so many failed microservice, SOA, or SCS-style systems that fail. They failed before the first line of code was written.

If you wonder what this business capability decomposing approach looks like in action, I have a couple of examples.

So, in my opinion, this is what you should start designing your system with.

Wrapping It Up

My point is simple: align your bounded contexts with business capabilities. Business capability mapping is a great instrument that facilitates this.

The way to manage your teams so that it doesn’t break Conway’s law is context mapping, which has some similarities with capability mapping and complements it in a way that makes use of both techniques really profitably.