In short
Bounded context is a central pattern from domain-driven design (DDD): an explicitly drawn boundary within which a particular domain model and its business terms apply unambiguously. Outside this boundary, the same word may mean something else.
The pattern helps you to cut large systems in such a way that teams, code and databases do not founder on contradictory terms.
What is a bounded context? The definition according to Eric Evans
The term was coined by Eric Evans in his book "Domain-Driven Design: Tackling Complexity in the Heart of Software", published by Addison-Wesley in August 2003. In his later summary, the DDD Reference of 2015, Evans defines the bounded context as a description of a boundary, typically a subsystem or the work of a specific team, within which a particular model is defined and applicable.
The starting point is a sober observation: in every larger project, several models exist at the same time. Different user groups need different views, teams solve the same problem independently of each other, tools differ. According to Evans, if parts of the code based on different models are mixed in an uncontrolled way, software becomes buggy, unreliable and difficult to understand.
His answer to this is: define the scope of a model explicitly. The boundary is made visible on three levels:
- Organisationally: which team is responsible for the model?
- Functionally: in which parts of the application is it used?
- Physically: which code base and which database schema belong to it?
Within the boundary, continuous integration and a shared language ensure that terms remain consistent. What happens outside should deliberately not distract the team. Martin Fowler sums this up in his bliki entry "BoundedContext" from 2014: large domains are divided into contexts, each with an internally consistent model, and the relationships between these contexts are described explicitly.
Bounded context, ubiquitous language and domain model
The bounded context is closely linked to two other basic DDD terms. According to Evans, the domain model is a system of abstractions that describes selected aspects of a business domain and is used to solve business problems. A model is therefore never a complete representation of reality but a deliberate selection. That is exactly why a framework is needed in which this selection applies.
The ubiquitous language is the shared language that domain experts and developers use consistently within a bounded context: in conversation, in diagrams, in tickets and above all in the code. Classes, methods and modules bear the names that the business department also uses. If the language changes, the model changes.
The addition "within" is decisive. A ubiquitous language is never valid across the whole company. It applies in exactly one bounded context. The context is therefore the language boundary at which terms may change their meaning. Fowler calls such ambiguous words polysemes and uses the example of an energy supplier to show how the word "meter" referred to a grid connection, a customer relationship or the physical device, depending on the department.
How do you find the boundaries of a bounded context?
There is no calculation method that automatically delivers context boundaries. In practice, three signals have proven effective, and you should combine them. How this works in a concrete project is described in more detail in the article domain-driven design in practice.
Language differences as the strongest signal
Pay attention to where the same word is given different attributes, rules or life cycles. If accounting thinks of payment terms and creditworthiness when it hears "customer" but support thinks of tickets and contact persons, there is probably a context boundary in between. Conversely, two different words for the same concept are an indication that the language within a context has not yet been clarified.
Event storming as a workshop method
Event storming, developed by Alberto Brandolini, is a workshop format in which domain experts and developers collect business events on a long timeline, such as "quote sent" or "machine delivered". The official EventStorming site describes it as a flexible format for the collaborative exploration of complex business domains. Where responsibilities, terms or the timing of events change, candidates for context boundaries emerge.
Team boundaries and Conway's law
In 1968, in his article "How Do Committees Invent?" in the magazine Datamation, Melvin Conway formulated the thesis that organisations design systems whose structure copies their communication structure. For bounded contexts this means: a context that three teams are jointly responsible for runs the risk of breaking up into three different models. Plan contexts so that each belongs to exactly one team. One team may well look after several contexts.
Context mapping: how bounded contexts work together
A single bounded context solves only half the problem. Systems have to exchange data, and at every connection point one model threatens to "leak" into the other. That is why Evans recommends a context map: an overview that names each model in the project, delimits its context and describes the points of contact, including translations, shared parts and power relationships.
One sentence from the DDD Reference is important here: "Map the existing terrain." The context map first shows the current state, including unattractive legacy burdens. Only then are changes planned. Many patterns describe an upstream/downstream relationship: the upstream team's decisions influence the success of the downstream team, but not the other way round.
| Pattern | Relationship | Core idea | Typical use |
|---|---|---|---|
| Partnership | Mutually dependent | Two teams plan and integrate together because both can only succeed together | Two contexts that only deliver release value together |
| Shared kernel | Tightly coupled | A small, explicitly delimited part of the model and code is shared and only changed by agreement | Shared core terms of two closely related teams |
| Customer/supplier development | Upstream/downstream | The needs of the downstream team feed into the planning of the upstream team | An internal platform team supplying business teams |
| Conformist | Upstream/downstream | The downstream team adopts the upstream model unchanged | Upstream has no incentive to adapt, and the model is usable |
| Anticorruption layer | Upstream/downstream | An isolating translation layer protects your own model from the foreign one | Connecting legacy systems or weak external models |
| Open-host service | Upstream for many | An open protocol makes a subsystem accessible as services for all consumers | A context in high demand with many consumers |
| Published language | Shared exchange format | A well-documented, shared language serves as the medium of translation | Industry standards for data exchange, often combined with an open-host service |
| Separate ways | No connection | A context is deliberately run without any integration | Integration costs more than it delivers |
The DDD Reference also adds the big ball of mud as a pattern for areas without recognisable model boundaries. There, Evans explicitly marks partnership and big ball of mud as terms that were only added after the original book. For connecting legacy software, the anticorruption layer is particularly relevant because, according to Evans, it requires little or no change to the legacy system.
Bounded context vs subdomain vs microservice vs module
These four terms are often mixed up but describe different things. A clean separation helps you with architecture decisions.
- Subdomain belongs to the problem space: it is a business area of the company, such as sales, production or customer service. Evans distinguishes the core domain, i.e. what sets your company apart, from generic subdomains. Vaughn Vernon adds supporting subdomains in "Implementing Domain-Driven Design" (2013).
- Bounded context belongs to the solution space: it is the boundary within which a concrete model applies. Ideally, one context covers exactly one subdomain; in systems that have grown over time, this is rarely the case.
- Microservice is a deployment unit, i.e. an independently deliverable process. A bounded context can consist of several microservices. But a microservice should never mix several contexts.
- Module is a code structure within an application. In a modular monolith, each module maps a bounded context, with its own language, its own data access and a clear interface, but a shared deployment.
The modular monolith is a sensible starting point for many systems in mid-sized companies. In his article "MonolithFirst" from June 2015, Martin Fowler argues that stable service boundaries essentially mean drawing the right bounded contexts and that even experienced architects often set these boundaries wrongly at the beginning. In a monolith, wrong cuts can be corrected much more cheaply than between distributed services.
Example: the "order" at a fictitious machine builder
The following scenario is a deliberately simplified, hypothetical example. A mid-sized machine builder manufactures packaging systems and runs sales, production and service. All three departments talk about the "order" every day, but each means something different:
- Sales: the order is a customer order with configuration, price, discount, payment terms and a promised delivery date. Its life cycle ends with the order confirmation and later the invoice.
- Production: the order is a production order with a bill of materials, routing, lot size and machine allocation. Prices play no role here. Several production orders can arise from one customer order.
- Service: the order is a service order for a specific system that has already been delivered, with serial number, fault description, technician, spare parts and response time.
A single "order" data model for all three areas would turn into a catch-all table with dozens of optional fields whose meaning only insiders still know. With three bounded contexts, each area gets its own lean model. They are connected via stable identifiers such as the order number and the serial number, as well as via business events.
When sales confirms a customer order, its context publishes, for example, the event "customer order confirmed". Production translates it into its own production orders. If production is also attached to an older ERP system, an anticorruption layer protects the production model from its data structures. After delivery, the service context only takes over system data and the serial number, but not prices or routings.
Common mistakes when cutting bounded contexts
- Equating bounded context with microservice. Anyone who immediately rolls out every context as a service of its own pays the overhead of distributed systems early, before the boundaries are stable.
- Cutting by technical layers. "Front end", "back end" and "database" are not business contexts. Boundaries follow the language and the business rules.
- Striving for a uniform, company-wide model. Evans considers a complete unification of the domain model of large systems neither feasible nor cost-effective. The canonical "customer for everyone" object creates exactly the ambiguity that contexts are meant to avoid.
- Secretly sharing database tables. If two contexts access the same tables, an unplanned shared kernel without agreement arises. Every schema change becomes a risk and increases technical debt.
- Only drawing the target picture. A context map that hides the current state conceals the actual dependencies and leads to unrealistic migration plans.
- Ignoring team structures. Contexts without a clear owner become watered down because nobody decides on the language and the model.
Frequently asked questions about bounded contexts
How big should a bounded context be?
There is no fixed size. A context is cut correctly if its language is free of internal contradictions, one team is responsible for it and it can be connected to other contexts with manageable interfaces. Contexts that are too small create a lot of integration effort; contexts that are too large lose their linguistic clarity. Evans himself points out that ever smaller contexts eventually cost valuable coherence.
Is a bounded context the same as a microservice?
No. The bounded context is a business model boundary, the microservice a technical delivery unit. A context can be implemented as a module in a monolith, as one service or as a group of several services. Conversely, a service should never mix models from several contexts.
What is the difference between a subdomain and a bounded context?
The subdomain describes a business area of the company, i.e. the problem. The bounded context describes the boundary of a software model, i.e. the solution. Ideally they correspond one to one. In systems that have grown over time, one context often covers several subdomains, which can be an indication that restructuring is needed.
Are bounded contexts worthwhile even without full DDD?
Yes. Even a simple context map of your existing systems makes dependencies, translation points and conflicting terms visible. The strategic DDD patterns can also be used without consistently applying the tactical building blocks such as aggregates or repositories. Especially when replacing legacy systems, thinking in contexts is the more valuable part.