Domain-Driven Design
In a DabbaGo meeting, the sales lead says "an order is confirmed when payment clears". The kitchen manager says "no, an order is confirmed when the cook accepts it". The rider lead says "an order is done when I hand it over". They are all right, about different things. The code, meanwhile, has one Order class with 60 fields trying to satisfy all three, and every team is afraid to touch it.
The rule
Speak the business's language, and give each meaning its own boundary.
Domain-driven design (DDD) is an approach to building software for complicated businesses. Its core ideas:
- Domain: the business area the software serves: taking lunch orders, cooking, delivering, paying kitchens.
- Ubiquitous language: the words the business experts use, used exactly the same way in conversations, documents and code. If kitchens say "ticket", the code says
Ticket, notOrderRecordV2. - Bounded context: a boundary inside which each word has one precise meaning and one model. Across boundaries, the same word may mean something else, and that is fine.
DabbaGo has at least three contexts:
| Context | "Order" there means | Key fields |
|---|---|---|
| Ordering | A customer's purchase | items, price, payment status |
| Kitchen | A cooking ticket | dishes, cook, ready time |
| Delivery | A drop-off | address, rider, time window |
Contexts talk through clear connections, often events. When a customer pays, Ordering publishes OrderPlaced with the order ID; Kitchen creates its own ticket from it, and Delivery creates its own drop.
Inside a context, DDD offers building blocks:
- Entity: something with an identity that lasts, like a specific customer.
- Value object: something defined only by its values, like an address or an amount of ₹180.
- Aggregate: a cluster of objects changed together through one root, which protects the rules, such as "an order's total always equals the sum of its items".
Bounded contexts are also natural lines for team ownership and, later, for services. That is why architects care about DDD even before writing code.
The shortcut
Listen for one word with two definitions. When experts argue about what a word "really" means, you have found a boundary between contexts, not a disagreement to settle.
Listen for clashing meanings
"Confirmed" means paid to sales, accepted to kitchens. Two definitions: a boundary.
The trap is the "one true model": forcing every team to agree on a single definition of Order. It creates a giant class everyone fears and no one owns.
Drills
Answer fast — trust the rule.
What is a bounded context?
The kitchen staff call a cooking job a "ticket". What does ubiquitous language suggest the code should call it?
Which of these is best modelled as a value object?
Sales and kitchens argue about what "confirmed" really means. What does DDD suggest?
Remember
- Speak the business's language, and give each meaning its own bounded context.
- Shortcut: one word with two definitions marks a boundary.
- Trap: forcing a single "one true model" on every team.