Kufijtë e mirë të shërbimit ndjekin aftësitë e biznesit, jo shtresat teknike. Domain-Driven Design (DDD) ofron një mjet të saktë për këtë: konteksti i kufizuar — një kufi brenda të cilit modeli i fushës dhe termat e tij janë konsistent.
Fjala "Klient" mund të nënkuptojë gjëra të ndryshme në kontekste të ndryshme. Çdo kontekst i kufizuar posedon modelin e vet, dhe një mikroshërbim zakonisht hartohet në një kontekst.
┌───────────────────┐ ┌────────────────────┐
│ 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
Nëse dy shërbime vazhdimisht thirren njëri-tjetrin për të përfunduar një operacion, kufiri është ndoshta i gabuar.
Kufijtë e vendosur herët janë shumë të kushtueshëm për t'u lëvizur më vonë, sepse ato ngurtësohen në API-të dhe bazat e të dhënave që ekipet e tjera mbështeten.
Kontekstet e kufizuara DDD ju japin mënyrën e përparë për të vizatuar këto linja përgjatë biznesit, kështu që shërbimetë mbeten koherente dhe mund të evoluojnë në mënyrë të pavarur në vend të koordinimit konstant.