Kako definirate granice servisa koristeći DDD ograničene kontekste?

Question

Accepted Answer

Dobre granice servisa slijede **poslovne mogućnosti**, ne tehničke slojeve. **Domain-Driven Design (DDD)** daje precizan alat za to: **ograničeni kontekst** — granica unutar koje su domenski model i njegovi uvjeti konzistentni.

## Ograničeni kontekst

Riječ "Customer" može značiti različite stvari u različitim kontekstima. Svaki ograničeni kontekst posjeduje svoj model, a mikroservis se obično mapira na jedan kontekst.

```text
┌───────────────────┐   ┌────────────────────┐
│  Sales context    │   │  Support context   │
│  Customer =       │   │  Customer =        │
│   leads, orders   │   │   tickets, SLAs    │
└───────────────────┘   └────────────────────┘
   one service             another service
```

## Kako pronaći granice

- **Usklađivanje sa poslovnim mogućnostima** (Narudžbe, Naplata, Dostava), ne s imenima ili DB tablicama.
- **Visoka kohezija iznutra, labava sprega preko** granice.
- Primjećujte gdje se **sveprisutni jezik** mijenja — to je obično rub konteksta.
- Koristite **kontekstnu mapu** za dokumentiranje odnosa (uzvodni/nizvodni).

## Antuzorci

```text
✗ 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
```

Ako dva servisa neprekidno pozivaju jedan drugoga da dovrše jednu operaciju, granica je vjerojatno pogrešna.

## Zašto je to važno

Granice odlučene rano su vrlo skupo premještati kasnije, jer se učvršćuju u API-je i baze podataka na koje se drugi timovi oslanjaju.

DDD ograničeni konteksti daju vam principijelan način crtanja tih linija duž poslovanja, tako da servisi ostanu kohezivni i mogu se razvijati neovisno umjesto da se stalno koordiniraju.