A DDD bounded context
A bounded context is the boundary within which a particular domain model holds, where every term has one agreed meaning and the model stays internally consistent. The same word, "account" or "customer" or "order", carries different meanings in different parts of a large system. A bounded context is the design decisionDecisionStrategyA recorded decision with context, rationale, and consequencesView reference → to stop pretending those meanings are the same and to draw an explicit line around each one.
Eric Evans introduced the bounded context in *Domain-Driven Design: Tackling Complexity in the Heart of Software* (2003). The book paired it with two companion ideas. The first is ubiquitous language: a shared vocabulary, spoken by domain experts and developers alike, that shows up directly in class names, methods, and database tables. The second is the context map, a picture of how the separate contexts relate, since a real system has several and they must talk to each other.
The argument runs from a hard limit. A single unified model across a large organisation collapses under its own ambiguity, because different teams genuinely mean different things by the same word. Evans' answer was to let each model be authoritative inside its own boundary and to manage the seams between boundaries deliberately, naming patterns such as shared kernel, customer/supplier, and anticorruption layer.
The thinking found a second life with microservices. Martin Fowler and others observed that a service boundary drawn along a bounded context tends to be stable, because it follows the shape of the business rather than the shape of the code. The reverse mistake, splitting services by technical layer or by noun, produces chatty, brittle systems. The bounded context gave teams a principled way to answer "where should this service end?"
A logistics company runs one system. In the Sales context, an "Order" is a commitment a customer has made: it has a price, a discount, and a payment status. In the Warehouse context, an "Order" is a pick list: a set of items, a bin location, and a packer. These are the same business event seen through two models, and forcing them into one shared Order class produces a tangle of nullable fields and conditional logic that serves neither team.
Drawing a boundary between Sales and Warehouse lets each keep its own Order definition. When Sales confirms a purchase, it publishes an event the Warehouse subscribes to and translates into its own pick list through a thin anticorruption layer. The two teams now deploy independently, and a vocabulary change in one context stops leaking into the other. The cost is the translation seam, which is real work, and the context map exists to keep that work visible.
In the Unified Product Graph, a bounded context anchors the engineering region's model of system structure. A product is partitioned by its contexts (product_bounded_by_bounded_contextbounded_context_deploys_servicebounded_context_modelled_as_aggregatebounded_context_emits_domain_eventbounded_context_decided_via_decision
Type-specific fields on BaseNode
team_ownerstringOwning team
tech_stackstring[]Technologies used within this context
ubiquitous_languagestringKey terms and their definitions
idstringrequiredUnique identifier (UUID)
typeNodeTyperequiredDiscriminator for the entity type
titlestringrequiredDisplay name
descriptionstringOptional detailed description
statusstringLifecycle status
tagsstring[]Freeform tags for filtering
14 edge types connected to this entity.
product_bounded_by_bounded_contextbounded_context_deploys_servicebounded_context_emits_domain_eventbounded_context_decided_via_decisionbounded_context_persisted_in_data_modelbounded_context_modelled_as_aggregatebounded_context_projected_as_read_modelbounded_context_stored_in_code_repositorybounded_context_integrates_via_integration_patternbounded_context_connects_to_external_apibounded_context_flows_through_data_flowbounded_context_publishes_api_contractbounded_context_contains_feature_areabounded_context_contains_feature2 frameworks use this entity type.