Bounded Contexts: The Big Picture

The "Same Word, Different Meaning" Problem

What is a "Customer"?

• To the Sales Department, a Customer is someone with a name, a credit rating, a sales pipeline stage, and an assigned account manager.
• To the Support Department, a Customer is someone with a ticket history, a current frustration level, and a preferred contact method.
• To the Billing Department, a Customer is someone with a payment method, an invoice history, and a subscription tier.

If you try to create one single, giant Customer class in your code that satisfies all three departments, you will end up with a bloated object carrying dozens of fields, most of which are irrelevant in any given context. Worse, a change made to satisfy the Sales team might accidentally break the Support team's workflows.

This is the polysemy problem — the same word meaning different things to different people.

Drawing Boundaries

DDD embraces this reality through the concept of the Bounded Context. A Bounded Context is an explicit linguistic and logical boundary. Inside that boundary, every term has a single, specific, unambiguous meaning and a single model.

Instead of one giant system, you design distinct subsystems — which in modern architectures often become separate microservices or service groups:

• In the Sales Bounded Context, Customer has fields: name, creditRating, pipelineStage, accountManagerId.
• In the Support Bounded Context, Customer has fields: name, openTicketCount, lastContactDate, satisfactionScore.
• In the Billing Bounded Context, Customer has fields: name, paymentMethodId, subscriptionTier, invoiceHistory.

These are three separate classes, in three separate codebases (or modules), each optimized for its own context. They may share a customerId to link records across contexts, but they do not share a class.

Context Maps: How Bounded Contexts Relate

When you have multiple Bounded Contexts, you need to define how they communicate. A Context Map is a document (or diagram) that shows all the Bounded Contexts in a system and the relationships between them. Common relationship patterns include:

• Shared Kernel: Two contexts share a small, common model that both teams agree to maintain together. Changes require coordination.
• Customer/Supplier: One context (upstream supplier) produces data that another (downstream customer) consumes. The downstream team can make requests but the upstream team sets the agenda.
• Conformist: The downstream context simply adopts the upstream context's model wholesale, with no translation. Used when the upstream is a powerful external system you can't influence (e.g., a payment gateway).
• Anti-Corruption Layer: The downstream context builds a translation layer to protect itself from the upstream's model. Covered in detail later in this lesson.