Kako definirate mejne pogoje storitev z omejenim kontekstom DDD?

Question

Accepted Answer

Dobre meje storitev sledijo **poslovnim zmožnostim**, ne pa tehničnim plastjem. **Domain-Driven Design (DDD)** ponuja natančno orodje za to: **omejen kontekst** — meja, v kateri sta domenski model in njegovi izrazi skladni.

## Omejen kontekst

Beseda "Stranka" lahko pomeni različne stvari v različnih kontekstih. Vsak omejen kontekst ima svoj model, in mikroservis se običajno preslika na en kontekst.

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

## Kako najti meje

- **Poravnajte s poslovnimi zmožnostmi** (Naročila, Obračun, Pošiljanje), ne s samostalniki ali tabelami podatkovne baze.
- **Visoka kohezija znotraj, ohlapna povezava čez** mejo.
- Bodite pozorni na mesto, kjer se **vsesplošni jezik** spremeni — to je običajno rob konteksta.
- Uporabite **zemljevid konteksta** za dokumentiranje odnos (upstream/downstream).

## Protiprimer

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

Če dve storitvi nenehno kličeta druga drugo, da dokončata eno operacijo, je meja verjetno napačna.

## Zakaj je to pomembno

Meje, odločene zgodaj, je zelo drago spremeniti kasneje, ker se utrdijo v API-je in podatkovne baze, na katere se zanašajo drugi oddelki.

Omejenianici konteksti DDD vam dajo načelen način za risanje teh črt po poslu, tako da storitve ostanejo skladne in se lahko razvijajo neodvisno, namesto da bi se nenehno usklajevale.