Limitele bune ale serviciilor urmăresc capacitățile de afaceri, nu straturile tehnice. Domain-Driven Design (DDD) oferă un instrument precis pentru aceasta: bounded context — o limită în cadrul căreia un model de domeniu și termenii săi sunt consecvenți.
Cuvântul "Customer" poate avea semnificații diferite în contexte diferite. Fiecare bounded context deține propriul model, iar un microserviciu se mapează de obicei pe un singur context.
┌───────────────────┐ ┌────────────────────┐
│ Sales context │ │ Support context │
│ Customer = │ │ Customer = │
│ leads, orders │ │ tickets, SLAs │
└───────────────────┘ └────────────────────┘
one service another service
✗ Entity services ("User service", "Product service") — too fine, chatty
✗ Splitting by technical layer (a "database service")
✗ Boundaries that force a distributed transaction for every operation
Dacă două servicii se apelează constant una pe cealaltă pentru a completa o operație, limita este probabil greșită.
Limitele decise devreme sunt foarte scumpe de mutat mai târziu, deoarece se întăresc în API-uri și baze de date pe care alte echipe depind.
DDD bounded contexts vă oferă o modalitate principiată de a trasa aceste linii de-a lungul afacerii, pentru ca serviciile să rămână coerente și să poată evolua independent în loc să se coordoneze constant.