Concepts
Bounded contexts and aggregates (DDD)
Intuition
Think of a large company: the word "customer" means one thing to the sales team (a potential buyer, with a history of contacts), another to finance (someone who owes or has already paid an invoice) and another to support (someone who opened a ticket). Trying to build a single "universal" customer record that serves everyone ends up as a mess nobody understands. The healthier path is for each area to have its own model, with its own vocabulary, and to agree clearly on how the areas talk to each other. Within each area, there are still small groups of things that must always be consistent with each other — like an order and its items, which can never end up with inconsistent totals — and these groups have a single "front door" through which every change passes.
How it works
In Domain-Driven Design, a bounded context is the explicit boundary within which a domain model is valid and the ubiquitous language has a single, consistent meaning; the same term, such as "Customer" or "Product", can legitimately have different models in different contexts, and trying to unify them into a single canonical model tends to create coupling and ambiguity. Relationships between contexts are described in a context map, with patterns such as customer/supplier (in which the downstream context can negotiate its needs with the upstream one), conformist (in which the downstream adopts the upstream model without being able to influence it), and anti-corruption layer (a translation layer that keeps another context's model from leaking into yours). Within a context, the model is organized into aggregates: clusters of entities and value objects treated as a unit of consistency, with a single aggregate root that is the only external access point and the one that guarantees the invariants of the whole. Other objects reference an aggregate only by the root's identifier, and the rule of thumb is that a transaction modifies a single aggregate, so the invariants that must hold at every commit all sit inside one boundary. Between aggregates, and between contexts, consistency is eventual: an aggregate publishes domain events describing facts that occurred, and other aggregates or contexts react to them in their own transactions. When a business process spans several aggregates or services, that is where sagas come in, coordinated by orchestration or choreography; this concept is about where to draw the boundaries and what must be consistent inside them, not about how to coordinate what crosses them.
In practice
In practice, service boundaries in microservices tend to work best when they follow bounded contexts, because each service gets its own model, storage and vocabulary, and calls between services happen at the seams of the context map, where an anti-corruption layer protects a clean model from legacy or external integrations. Small aggregates, designed around real business invariants, avoid large transactions and lock contention, at the cost of accepting eventual consistency and domain events between them. The canonical references on the topic are Eric Evans, "Domain-Driven Design" (2003), which introduces bounded contexts and aggregates, and Vaughn Vernon, "Implementing Domain-Driven Design" (2013), which details aggregate design and integration between contexts.
Use it in a design
Practice the cases that rely on this concept in the System Design school.