Bounded Context DDD Lab (Interactive)
Toggle between one God User object and four bounded contexts to see loaded state and breakage risk collapse. The same "user" means Registered User, Customer, Recipient, and Shopper to four contexts. Load each model and compare object bloat against team coordination cost.
Bounded Contexts vs the God Object
One real-world “person” diverges into four domain models. Flip the modeling strategy and watch coupling, memory and coordination cost react.
Identity & Access
class User
- user_id: UUID
- password_hash
- mfa_secret
- roles: string[]
- jwt_session_id
Authentication, authorization, token validation.
Billing & Payments
class Customer
- customer_id: UUID
- stripe_customer_token
- vat_number
- billing_currency
- credit_balance
- tax_exemption_id
Payment capture, tax calculation, invoicing.
Logistics & Fulfillment
class Recipient
- recipient_id: UUID
- shipping_address
- delivery_gate_code
- courier_instructions
- sms_phone
- preferred_window
Packaging, courier dispatch, route optimization.
Product Catalog
class Shopper
- shopper_id: UUID
- wishlist: Sku[]
- brand_preferences
- ab_group
- loyalty_tier
- locale
Personalization, browse analytics, merchandising.
Each Bounded Context keeps its own ubiquitous language (User / Customer / Recipient / Shopper), and an Aggregate Root such as Order enforces invariants inside one transaction. Cross-context coordination happens through immutable domain events, never shared object graphs.
How It Works Under the Hood
In Domain-Driven Design, a bounded context owns one definition of every term, making its model small, explicit, and independently evolvable. A shared God Object forces the union of every team's fields onto every service: the billing service loads marketing preferences it will never read, and one team's schema change breaks three other teams. Ubiquitous language fails when "customer" and "recipient" are the same class. Splitting into bounded contexts shrinks loaded state per service and converts cross-team schema negotiations into four independent vocabularies.
Core Architectural Principles
- God Object mode loads the union of all four context models, inflating bytes loaded per request.
- Context mode gives each of User, Customer, Recipient, and Shopper only its own attributes.
- Coordination meetings and breakage risk scale with teams sharing one model instead of bounded contexts.
When asked how to find service boundaries, answer with DDD vocabulary: identify bounded contexts where one term has one meaning, and give the classic "user is four different entities in four domains" example. Mention context mapping between boundaries and warn that premature micro-DSs per table is context sprawl, not DDD.
Bounded contexts buy independent evolution and small models versus translation layers and duplicated data across boundaries.