Topic 11.2
Service Boundaries
In one line
Where services get cut — domain events, not CRUD tables — the 'bounded context' idea from DDD.
Think of it like this
Dividing a company into departments — Sales, HR, Warehouse. You draw the lines around groups of work that change together and talk to each other a lot, not by picking random people alphabetically.
Key ideas
- 01
Boundary by business capability (orders, payments, inventory, shipping), not by table (user-service ≠ everything touching users).
- 02
Each service owns its schema; cross-service reads happen via APIs (or event copies), never shared tables.
- 03
Domain events (OrderPlaced, PaymentFailed) are the seams — services communicate facts, not table updates.
- 04
The boundary test: if two services both mutate the same concept, the boundary is wrong.
- 05
DDD terms interviewers like: aggregate, bounded context, ubiquitous language — say them with a concrete example (order aggregate).
- 06
And: an anti-pattern is the distributed monolith — services that only split on paper but deploy/shared-schema like a monolith.
Explain without notes
Why is 'users service' with an accounts table and an auth table the same service — and when does auth deserve its own?
Practice
Carve the food-delivery domain into services: list capabilities, their DBs, and the event contracts.
Trade-offs
- ↔
Fine-grained services maximize autonomy and maximize integration cost; coarse-grained reverse it.
Run it in production
You've designed it. Now build, operate, and break the same idea hands-on in the DevOps courses:
Completion checklist
I draw boundaries by capability and events, never by CRUD table.