A jó szolgáltatási határok az üzleti képességeket követik, nem a technikai rétegeket. A Domain-Driven Design (DDD) ennek egy precíz eszközét biztosítja: a szegmentált kontextust — egy határt, amelyen belül a domain modell és annak feltételei konzisztensek.
A "Customer" szó különböző kontextusokban különbözőt jelent. Minden szegmentált kontextus saját modelljét kezeli, és egy mikroszolgáltatás jellemzően egy kontextusra térképez.
┌───────────────────┐ ┌────────────────────┐
│ 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
Ha két szolgáltatás folyamatosan egymást hívja egy művelet befejezéséhez, a határ valószínűleg helytelen.
A korai döntések alapján meghúzott határok később nagyon drágák az átmozgatása, mert API-kba és adatbázisokba merevülnek, amelyekre más csapatok támaszkodnak.
A DDD szegmentált kontextusai elvet nyújtanak ahhoz, hogy ezeket a vonalakat az üzlet mentén húzzuk, hogy a szolgáltatások koheívek maradjanak, és függetlenül fejlődhessenek, ahelyett hogy állandóan koordinálnának.