How do bounded contexts (from Domain-Driven Design) inform where you draw microservice boundaries, and what concrete symptoms show up when a service's boundary crosses into a neighboring bounded context?

## What a bounded context is **Bounded context**, a term from Domain-Driven Design, denotes the boundary within which a particular domain model and its vocabulary carry one consistent meaning; outside that boundary, the same word can mean something else entirely without it being an error. Applied to microservices decomposition, the practical rule is: - each service should sit inside exactly one bounded context; - and while one context can occasionally span a small, tightly related cluster of services, a single service should never straddle two contexts. ## How you apply it The mechanism for using this in practice starts with a **context map** — usually produced through domain discovery work with the people who run the business, not derived from an ER diagram — that names each context and the words that belong to it. For each candidate service boundary, you then ask a concrete test: does this service's internal model stay consistent, with every term meaning exactly one thing throughout? If a proposed `'Customer'` service tries to serve both the billing team's notion of a paying account and the support team's notion of a person with tickets, that's a sign the service actually spans two contexts and should be split along that seam, with each half getting its own model. ## Why it exists This exists to solve a very specific coupling problem: without an explicit context-aware boundary, teams default to drawing service lines around convenient technical artifacts — a database table, an existing module folder, an org chart division — none of which reliably tracks where the business's own conceptual boundaries actually are. When the service boundary doesn't match a bounded context, two services end up implicitly sharing one underlying model even though they're deployed separately, and every difference in how that model needs to evolve on each side becomes a cross-team negotiation. Aligning services to bounded contexts front-loads that negotiation into an explicit modeling exercise instead of letting it leak out as ongoing coordination overhead. ## The trade-off The trade-off is genuine effort spent upfront, and a result that can look wasteful to someone unfamiliar with the reasoning: you might end up with 'Customer' modeled three separate times, once each in Billing, Support, and Marketing services, each with different fields, different validation rules, and no single canonical schema. Teams new to this often push to unify these into 'one Customer service' to reduce apparent duplication — but that reintroduces the very coupling the split was meant to avoid, because now a change driven by Marketing's needs (adding a loyalty-tier field) forces a deploy and review cycle involving Billing and Support too, even though it has nothing to do with either. The cost of doing this right is **discipline**: someone has to keep re-explaining why 'three Customers' isn't duplication, and building the connective tissue (shared identifiers, integration events, anti-corruption layers) between them takes real engineering time that a shared-table shortcut would skip. ## Symptoms of a crossed boundary When boundaries cross a context anyway, the symptoms show up quickly and concretely. - You'll see services querying another team's database tables directly to work around an API that doesn't expose what they need — a sure sign the two are really one model split in two. - You'll see a field whose meaning silently differs between two services (an 'active' flag meaning 'has a valid subscription' in one place and 'logged in within 30 days' in another) causing subtle bugs whenever data crosses the boundary without translation. - You'll see repeated, contentious meetings about 'whose schema is the real one,' and a service that keeps absorbing unrelated responsibility because it was cast as the system's canonical owner of a widely-used noun. ## A worked example A concrete way this plays out: an online retailer separates its Sales bounded context from its Fulfillment bounded context and its Billing context, and each gets its own `Order`: | Context | What an `Order` is there | |---|---| | Sales | a priced, promised set of line items | | Fulfillment | a physical pick-pack-ship workflow | | Billing | an invoiced, collected amount | Each context gets its own service and its own local 'Order' representation scoped to what it needs — Sales doesn't track warehouse bin locations, Fulfillment doesn't track payment method. They're connected not by sharing one Order table but through domain events: Sales publishes `OrderPlaced`, which Fulfillment and Billing each consume and translate into their own model through a small **anti-corruption layer**, so an internal restructuring of Sales's Order model never forces a synchronized deploy of Fulfillment or Billing. This is the practical output of context-aligned decomposition: services that can evolve independently because they were never sharing a model in the first place, just a stream of well-defined events at the seam.