Bounded Context — What It Is and Why It Matters

The unified-model trap

In any non-trivial enterprise, different teams use the same words to mean different things. Sales 'Customer' is a prospect with a lead score. Shipping 'Customer' is a delivery address. Support 'Customer' is a ticket holder.

The instinct is to build one Customer class that serves everyone — and that's exactly how domain models become incoherent. The class accumulates fields nobody needs, validation rules contradict each other, and a sales-specific change ships with shipping deploys.

Bounded Contexts solve this by drawing explicit boundaries around cohesive models, each with its own Ubiquitous Language, where every term has one precise meaning. The duplication across contexts is intentional — it's cheaper than the coupling a unified model creates.

Visualizing the boundary

Three contexts, three different Customer classes, all correct. Cross-context flow happens through events with primitive payloads (OrderSubmittedEvent), not by importing each other's domain classes.

Ubiquitous Language per context

A BC has its own vocabulary that lives in the code. Sales: customer.qualify(criteria), Opportunity. Support: customer.escalate(reason), Ticket. The verbs and nouns are different because the language is different.

If you and a domain expert disagree about what a word means, ask which context they're in. If the answer is 'both' — you've found a boundary.

BC ≠ microservice

Most common confusion. A BC is a design boundary; a microservice is a deployment unit.

• A monolith can contain many BCs as separate top-level packages or Java modules
• A microservice typically corresponds to one BC — but a single BC can be backed by multiple physical services (CQRS read + write)
• Decide BC boundaries first (language, team, data); deployment second

Equating them leads to premature decomposition — splitting before you understand the domain, drawing boundaries on the wrong lines.

Modular monolith is often the right start: BCs as modules, sharing a deployable, ready to extract when team/scaling pressure justifies.

Enforcing boundaries in code

Without enforcement, boundaries erode — 'just import Customer from sales because it has the field I need.'

Java packaging: com.company.sales., com.company.shipping., com.company.shared (tiny stable kernel).

ArchUnit rules in CI: noClasses().that().resideInAPackage('..sales..').should().dependOnClassesThat().resideInAPackage('..shipping..'). Build fails on violation.

Java 9+ modules give compile-time enforcement — internal classes invisible cross-BC.

Data ownership per context

Each BC owns its own tables/schema, even in a shared DB. sales.customers, shipping.customers, support.customers — separate.

No cross-context joins. Shipping needs customer name from Sales? It arrives in OrderSubmittedEvent payload and stored locally in shipping.customers — denormalized copy.

Why: each BC functions if others unavailable. Schema migrations don't cascade. Future microservice extraction = replace in-process events with Kafka, move schema to its own DB. Domain model and app logic don't change.

Skipping data isolation in monolith phase → painful microservice extraction later.

Translation at boundaries

Never share domain classes. Use:

• Domain events with primitive payloads
• Anti-Corruption Layer in consuming context (translates foreign model to local). Critical for legacy/third-party integration
• Published Language — versioned schema (Avro, Protobuf, OpenAPI) both sides agree on
• Shared Kernel — small set of common value objects (Money, EmailAddress, CustomerId). Keep small and stable

Rule: the consuming context controls the translation.

Common mistakes

• 'BC = microservice'
• One canonical Customer class in a common package
• Cross-context table joins
• 'common-domain' Maven module that grows organically — unified model with extra steps
• No build-time enforcement
• Boundaries on technical lines (read vs write) instead of language lines
• Over-fragmenting — two BCs for what is genuinely one model

Recommendation

Discover Bounded Contexts by language and team boundaries, not by technical or deployment concerns. Implement them as packages or Java modules in a monolith first; let microservice extraction be a separate, deferred decision. Each BC owns its data, expresses its own Ubiquitous Language in code, and translates explicitly at boundaries via events, an ACL, or a small Shared Kernel. Enforce the boundary with ArchUnit in CI. Equating BC with microservice is the single most common DDD mistake — it leads to premature decomposition and cross-service refactor pain.