← Microservices learning pathMicroservices · Module 2 of 10
Designing service boundaries
Decide what each service should own.
📖 Key ideas
- Use Domain-Driven Design (DDD): bounded contexts define boundaries.
- Services should be loosely coupled and highly cohesive.
- Each service owns its data (database per service).
- Avoid chatty services that call each other constantly.
- Start coarse; split as understanding grows.
💡 Real-life example: Bounded contexts are departments: Accounts and Delivery may both say "order" but mean different things.
DDDDomain-Driven Design
Bounded contextBoundary where a model applies
Database per serviceEach service owns its data
Chatty serviceToo many fine-grained calls