Bounded Contexts and Domain-Driven Design

Where one model ends and another begins

Domain-Driven Design (DDD), introduced by Eric Evans, gives the most useful tool for drawing boundaries: the bounded context. A bounded context is a part of the system within which a model and its language (the ubiquitous language) are consistent. The word "Product" means different things to Catalogue (descriptions, images, categories), Inventory (stock per warehouse) and Pricing (base price, discounts, taxes). Trying to build one shared Product model for everyone creates a bloated class that every team fights over. Instead, each context has its own model and they translate at the edges. A context map documents relationships: customer-supplier, conformist, shared kernel, and anti-corruption layer (a translation layer protecting your model from a messy external one). Bounded contexts make excellent module boundaries in a monolith and are the usual starting point for service boundaries.

One word, three models

Each context keeps only what it needs and links by ID.

# catalogue context
@dataclass
class Product:
    sku: str
    title: str
    description: str
    images: list[str]
    category: str

# inventory context
@dataclass
class StockItem:
    sku: str
    warehouse: str
    on_hand: int
    reserved: int

# pricing context
@dataclass
class PriceRule:
    sku: str
    base_price_minor: int
    currency: str
    gst_rate: Decimal
    active_discounts: list[str]

The word "account" at a bank

To the savings desk, an account is a balance and interest rate; to the loans desk, it is a repayment schedule; to IT, it is a login. Each desk keeps its own file and they share only the customer number.

त्वरित जाँच: What is a bounded context?

• A database table
• A Kubernetes namespace
• A type of API gateway
• A boundary within which one domain model and its language stay consistent