Kuinka määrität palvelun rajat käyttämällä DDD bounded contexteja?

Question

Accepted Answer

Hyvät palveluiden rajat noudattavat **liiketoiminnallisia kykyjä**, eivät teknisiä kerroksia. **Domain-Driven Design (DDD)** tarjoaa tarkan työkalun: **bounded context** — raja, jonka sisällä verkkotunnuksen malli ja sen ehdot ovat johdonmukaisia.

## Bounded context

Sana "Customer" voi tarkoittaa eri asioita eri yhteyksissä. Jokainen bounded context omistaa oman mallinsa, ja microservice yhdistetään tyypillisesti yhteen kontekstiin.

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

## Kuinka löytää rajat

- **Kohdista liiketoiminnallisiin kykyihin** (Orders, Billing, Shipping), ei substantiiveihin tai tietokantaan tauluihin.
- **Korkea koheesio sisällä, löyhä kytkentä** rajan yli.
- Tarkkaile, missä **ubiquitous language** muuttuu — se on yleensä kontekstin raja.
- Käytä **context map** -kuvausta suhteiden dokumentointiin (upstream/downstream).

## Anti-patterns

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

Jos kaksi palvelua kutsuvat jatkuvasti toisiaan yhden operaation suorittamiseksi, raja on todennäköisesti väärä.

## Miksi se on tärkeää

Aikaisen määrittelyn rajat ovat erittäin kalliita siirtää myöhemmin, koska ne kovettuvat API:ksi ja tietokannoiksi, joista muut tiimit ovat riippuvaisia.

DDD bounded contexts antaa sinulle periaatteellisen tavan piirtää nämä viivat liiketoiminnan mukaisesti, jotta palvelut pysyvät yhtenäisinä ja voivat kehittyä itsenäisesti jatkuvan koordinoinnin sijaan.