როგორ განსაზღვრავთ სერვისის საზღვრებს DDD შეზღუდული კონტექსტის გამოყენებით?

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).

## ანტიპატერნები

```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-ი გაწვდით პრინციპიურ გზას ამ ხაზების დახაზვისთვის ბიზნესის გასწვრივ, ასე რომ სერვისები რჩებიან კოჰეზიური და შეუძლიათ დამოუკიდებლად განვითარდნენ, ვიდრე მუდმივად კოორდინაციას ახორციელებენ.