Boundaries that follow the business
🎯You'll be able to
Find boundaries from the business's own language and capabilities, using the idea of bounded contexts.
🏠The everyday picture
In a hospital, "patient" means something different at the front desk (name, insurance), in the ward (bed, medication) and in billing (invoices, payments). Each department keeps the details it needs and uses its own words.
📘What it really is
- A business capability is something the business does: take orders, take payments, raise invoices, tell customers.
-
A bounded context (from domain-driven design) is a part of the system where words have one clear meaning and one model is used. "Order" in the kitchen (dishes to cook) differs from "order" in payments (an amount to capture).
-
Draw boundaries around capabilities, not technical layers. "Payments" is a good boundary; "database layer" isn't.
- Each boundary owns its data. Others ask it; they don't keep copies they change.
- Listen for language: when one word means two things in two teams, there is probably a boundary between them.
📝A worked example
Input: RasoiRoute's six modules and a kitchen manager's description: "When an order comes in, we price it, take the money, raise the GST invoice and send the customer an SMS."
Steps:
- Capabilities: pricing (catalogue), ordering, payments, invoicing, customer messages (notifications), reporting.
- Check language: in notifications, an "order" is just an ID, a phone number and a total; it doesn't need dishes.
- So notifications should receive what it needs in the message, not look the order up.
- Ownership: each module keeps its own records; notifications keeps sent messages only.
Expected output: six capabilities, each owning its data, and notifications needing nothing from orders.
🌍Where it's used
- Banks separate accounts, payments, cards and lending, each with its own idea of a "customer".
- E-commerce separates catalogue, cart, checkout and fulfilment.
- Government services separate identity, benefits and payments.
📝Case scenario
A school app had one "Student" record used for admissions, timetables, fees and transport, with 90 fields. Every change needed four teams' agreement. Splitting it into a student record per context, linked by a student ID, let each team change its own fields.
🖱️Try it
Ask someone who works in a business (a shop, a clinic) to describe their day. Underline the verbs (take orders, book, bill). Group them into three to six capabilities. Success: each group could be owned by one team.
⚠️Common mistakes
- Technical layers as boundaries. Sign: a "services" folder and a "models" folder. Fix: group by capability.
- One shared model for everything. Sign: a 90-field record. Fix: a model per context, linked by ID.
- Boundaries from the org chart alone. Sign: lines that cut a capability in half. Fix: start from the capability, then check the teams.
🛠️For your project
Project 2's notifications front door takes { orderId, phone, total, invoiceNo }: everything it needs, so it never reads orders.
✅Quick check
What is a bounded context?
Show the answer
A part of the system where words have one clear meaning and one model is used.
Why draw boundaries around business capabilities rather than technical layers?
Show the answer
Changes usually come from the business, so they stay inside one part, owned by one team.