Finding your service boundaries - a practical guide
summary
Argues that service boundaries come from use cases not entities and shows a concrete pattern: in an Amazon-style checkout create the order ID at workflow start and send thin events with IDs while shipping and finance receive addresses and payment details in separate messages, avoiding fat coupled events. Demonstrates a modeling technique using anti-requirements to separate unrelated data, insists on decoupling logical services from physical systems (microservices are a deployment concern), and warns migration often takes years.
AI-written summary · about
chapters (11)
- 0:00Introduction and context
- 2:16The big ball of mud
- 7:37The distributed ball of mud
- 10:13Designing message workflows
- 14:34Thin events and UI ownership
- 19:00Defining service boundaries
- 24:38Service modeling techniques
- 30:00Bottom-up modeling in practice
- 35:48Organizational structure issues
- 38:34Microservices vs. logical services
- 44:26Conclusion and legacy systems
related talks
58mFinding your service boundaries - a practical guide
50mFinding Your Service Boundaries - a Practical Guide
58mFinding your service boundaries - a practical guide
16mMicroservices Paradise: is it possible to achieve?
47mGetting (service) design right
26mDrawing the right lines: DDD, APIs and Microservices
01h 01mCapability Mapping
55mCapability Mapping