Πώς ορίζετε τα όρια της υπηρεσίας χρησιμοποιώντας DDD bounded contexts;

Question

Accepted Answer

Τα καλά όρια υπηρεσίας ακολουθούν **επιχειρηματικές δυνατότητες**, όχι τεχνικές στρώσεις. Το **Domain-Driven Design (DDD)** παρέχει ένα ακριβές εργαλείο: το **bounded context** — ένα όριο στο οποίο ένα μοντέλο τομέα και οι όροι του είναι συνεπείς.

## Bounded context

Η λέξη "Customer" μπορεί να σημαίνει διαφορετικά πράγματα σε διαφορετικά πλαίσια. Κάθε bounded context διαθέτει το δικό του μοντέλο, και μια microservice συνήθως χαρτογραφείται σε ένα πλαίσιο.

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

## Πώς να βρείτε όρια

- **Ευθυγράμμιση με επιχειρηματικές δυνατότητες** (Orders, Billing, Shipping), όχι ουσιαστικά ή πίνακες DB.
- **Υψηλή συνοχή εσωτερικά, χαλαρή σύζευξη κατά** το όριο.
- Παρατηρήστε όπου αλλάζει η **ubiquitous language** — αυτό είναι συνήθως ένα όριο πλαισίου.
- Χρησιμοποιήστε ένα **context map** για να τεκμηριώσετε τις σχέσεις (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
```

Εάν δύο υπηρεσίες συνεχώς καλούν η μια την άλλη για να ολοκληρώσουν μια λειτουργία, το όριο είναι πιθανώς λάθος.

## Γιατί έχει σημασία

Τα όρια που αποφασίστηκαν νωρίς είναι πολύ ακριβό να μετακινηθούν αργότερα, γιατί σκληρύνουν σε API και βάσεις δεδομένων που άλλες ομάδες εξαρτώνται.

Τα DDD bounded contexts σας δίνουν ένα αρχεσυνεπή τρόπο να σχεδιάσετε αυτές τις γραμμές κατά μήκος της επιχείρησης, έτσι ώστε οι υπηρεσίες να παραμείνουν συνεκτικές και να μπορούν να εξελιχθούν ανεξάρτητα αντί να συντονίζονται συνεχώς.