What is a bounded context in domain-driven design and how does it map to microservices?

Expected Interview Answer

Step-by-Step Explanation

1. Step 1

   Explore the domain

   Work with domain experts to map the business into subdomains and the language each area actually uses.

2. Step 2

   Draw context boundaries

   Group closely related concepts into bounded contexts where every term has one unambiguous meaning.

3. Step 3

   Define the ubiquitous language

   Agree on the vocabulary used inside each context and document where the same word means something different elsewhere.

4. Step 4

   Map relationships

   Use a context map to describe how contexts integrate — shared kernel, customer-supplier, or anti-corruption layer.

5. Step 5

   Assign services and data

   Give each bounded context its own microservice, owning its model and private database, communicating only through contracts.

Code Example

// Sales context: an Order is about winning a purchase
namespace Sales {
  export interface Order {
    orderId: string
    customerId: string
    total: number
    discountCode?: string
  }
}

// Fulfillment context: an Order is about shipping goods
namespace Fulfillment {
  export interface Order {
    orderId: string
    warehouseId: string
    items: { sku: string; quantity: number }[]
    shippingAddress: string
  }
}

// Each service owns its own model; they exchange a contract, not internals.
function toFulfillment(o: Sales.Order, address: string): Fulfillment.Order {
  return { orderId: o.orderId, warehouseId: 'W1', items: [], shippingAddress: address }
}

Follow-up Questions

• What is a context map and what relationship patterns does it capture?
• What is an anti-corruption layer and when do you need one?
• How do bounded contexts relate to subdomains (core, supporting, generic)?
• How do you avoid a distributed monolith when splitting by context?
• How does each service owning its own database follow from bounded contexts?