DDD Strategic Patterns: How To Define Bounded Contexts

And how to represent their communication

DDD owns the concepts of Core Domain, Generic Domain and Bounded Context. What is it, how to define them and is there any connection with business-capabilities?

Domain

Domain is the reality we inhabit: its entities, their behavior, 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 domain is called a Problem space.

Sub-domains

DDD implies domain decomposing into sub-domains, to ease their modelling 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 in modeling extracted sub-domains in their entirety. There is a certain set of rules in each sub-domain 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

Bounded context is a logical boundary
When both sub-domains and the core domain are defined, it’s time to implement the code. Bounded context defines tangible boundaries of applicability of some sub-domain. It is an area where a certain sub-domain 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 to look at the concept of a Bounded context.

From the run-time perspective, bounded context represents logical boundaries, defined by 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. So 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, the certain ubiquitous language is applied, and a certain terms make a clear sense, while the others don’t. Probably the best way to represent this areas is just 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 I designed my models around corresponding sub-domains. How many codebases a specific sub-domain is 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 sub-domains
It seems natural that the code belonging to some bounded context would implement a single sub-domain, 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 s sub-domain 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 DDD approach in mind. Bounded contexts in such systems can expose several sub-domains. What it might look like? Simple example, PSP, as usual. One sub-domain represents 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 sub-domains. So such systems might be aligned with our sub-domains 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 are more than one global goals, more than one motivation for change. I like these examples. Basically, they illustrate “Wrong reuse” chapter: decomposing your domain along nouns and putting all stuff 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.

So how to define sub-domains and bounded contexts?
And 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, SCS or how else you prefer to call your style systems fail. They had failed before the first line of code was written.

If you wonder how 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 usage of both techniques really profitable.