Goede servicegrenzen volgen bedrijfsmogelijkheden, niet technische lagen. Domain-Driven Design (DDD) biedt hiervoor een nauwkeurig instrument: de bounded context — een grens waarbinnen een domeinmodel en de bijbehorende termen consistent zijn.
Het woord "Customer" kan in verschillende contexten verschillende dingen betekenen. Elke bounded context bezit zijn eigen model, en een microservice wordt doorgaans toegewezen aan één 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
Als twee services elkaar voortdurend aanroepen om één operatie af te ronden, is de grens waarschijnlijk verkeerd.
Grenzen die vroeg worden bepaald, zijn later erg duur om te verplaatsen, omdat ze verstijven in API's en databases waarop andere teams vertrouwen.
DDD bounded contexts geven je een principiële manier om die lijnen langs het bedrijf te trekken, zodat services samenhangend blijven en onafhankelijk kunnen evolueren in plaats van voortdurend te coördineren.