Domain-Driven Design Basics
The problem
Large systems often model the same real-world word ('order,' 'customer') differently in different parts of the business, and forcing one single shared definition everywhere creates a model that's technically consistent but practically wrong for at least some of its users — domain-driven design gives a disciplined way to draw boundaries around where a model is allowed to mean one specific thing.
Why now
Layered architecture already established organizing code by responsibility; domain-driven design goes a level deeper, organizing an entire system's *model* around the business domain itself, using the same separation-of-concerns instinct but applied to meaning and language, not just technical layers.
Mental model
A bounded context is an explicit boundary around where a specific model and vocabulary applies — 'customer' in the billing context (has payment methods, an invoice history) is a legitimately different model from 'customer' in the support context (has tickets, a satisfaction score), and DDD says don't force them into one shared definition; give each its own model and translate deliberately at the boundary between them.
Requires
- Layered Architecture & Separation of ConcernsSoftware Architecture
A bounded context is separation of concerns applied to meaning and modeling rather than technical layers; you need the general discipline of drawing deliberate boundaries around responsibility before drawing them around domain models specifically.
Used in
- Large enterprise systems where the same business term means genuinely different things to different teams
- Microservice boundary design, often drawn along bounded-context lines rather than arbitrary technical splits
- Ubiquitous language — using the business's own vocabulary in code instead of inventing a parallel technical one
- Avoiding a single, ever-growing 'God model' that tries to serve every part of a business at once
Projects
- Identify two different parts of a hypothetical business (e.g. sales and support) that use the same term ('account,' 'customer') to mean subtly different things, and design a bounded context for each with its own model
- Design a translation layer between two bounded contexts, showing how a concept crossing the boundary gets deliberately reinterpreted rather than sharing one model
Examples
- In an e-commerce system, 'product' in the catalog context (description, images, category) is a different model from 'product' in the warehouse context (bin location, stock count) — forcing one shared Product model serves neither well
- A single, massive User model trying to serve authentication, billing, and support simultaneously accumulates fields and responsibilities none of those contexts individually need
Resources
Mastery checklist
- I can explain what a bounded context is and why forcing one shared model everywhere causes problems
- I can identify a term in a real system that means different things in different contexts
- I can design a translation layer between two bounded contexts
- I can explain 'ubiquitous language' and why matching the business's own vocabulary matters