I buoni confini dei servizi seguono le capacità aziendali, non gli strati tecnici. Domain-Driven Design (DDD) fornisce uno strumento preciso per questo: il bounded context — un confine all'interno del quale un modello di dominio e i suoi termini sono coerenti.
La parola "Cliente" può significare cose diverse in contesti diversi. Ogni bounded context possiede il proprio modello, e un microservizio in genere corrisponde a un contesto.
┌───────────────────┐ ┌────────────────────┐
│ 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
Se due servizi si chiamano costantemente l'uno con l'altro per completare un'operazione, il confine è probabilmente sbagliato.
I confini decisi in anticipo sono molto costosi da spostare in seguito, perché si trasformano in API e database su cui altri team fanno affidamento.
I bounded context di DDD ti danno un modo principiato per tracciare queste linee lungo l'azienda, in modo che i servizi rimangono coesi e possono evolversi in modo indipendente piuttosto che coordinare costantemente.