Bounded Context

A bounded context is an explicit boundary within which a model and its vocabulary have one consistent meaning. It is a central pattern in domain-driven design, and Martin Fowler’s summary of it states the reason it exists: “total unification of the domain model for a large system will not be feasible or cost-effective.” Instead, a large model is divided into several bounded contexts, and the relationships between them are made explicit.

The problem: one word, several meanings

Different parts of an organization use subtly different vocabularies, and the differences are easy to miss because the words are the same. Fowler’s example comes from an electricity utility, where “meter” meant a point of connection to the grid to one group, a customer’s connection to another, and the physical device to a third. Words like this — one term with several related meanings — are polysemes, and in his phrasing they “could be smoothed over in conversation but not in the precise world of computers.” He notes the same thing recurs with terms such as customer and product.

In a data platform the symptom is familiar: a customer table built for billing counts account holders, the one built for marketing counts people who opted in, and the one built for support counts anyone who ever raised a ticket. Each is correct inside its own context. The error is joining or comparing them as if “customer” meant the same thing.

Why a single enterprise model tends to fail

The natural response is to define every term once for the whole organization. That runs into the problem above: agreeing a single meaning means either forcing some groups to use a definition that does not fit their work, or making the definition so general that it is precise for nobody. Efforts of this kind can stall in negotiation, or produce a model that each team quietly reinterprets.

Working with boundaries instead

• Name the context with the term. “Billing customer” and “marketing contact” are different things and should be different columns, tables, or metrics.
• Share identifiers, not definitions. Contexts can agree on how to recognize the same person or account across systems without agreeing on everything else about them.
• Make translation explicit. Where data crosses from one context to another, write down the mapping and who owns it, rather than letting each consumer reinvent it.
• Share on purpose where sharing is needed. Some attributes genuinely must mean the same thing everywhere — the calendar, a product catalog used across processes. Those are agreed deliberately and owned, which is what conformed dimensions in dimensional modeling do.

The point is not to prevent shared meaning but to stop assuming it. How bounded contexts shape the difference between operational and analytical models is worked through in Operational and Analytical Models: Designed for Different Jobs.

References

• Martin Fowler, BoundedContext