DDD bounded contexts kullanarak hizmet sınırlarını nasıl tanımlarsınız?

Question

Accepted Answer

İyi hizmet sınırları **iş yeteneklerini** izler, teknik katmanları değil. **Domain-Driven Design (DDD)** bunu için kesin bir araç sağlar: **bounded context** — bir sınır, bunun içinde bir etki alanı modeli ve terimleri tutarlıdır.

## Bounded context

"Müşteri" kelimesi farklı bağlamlarda farklı şeyler anlamına gelebilir. Her bounded context kendi modelinin sahibidir ve bir mikro hizmet genellikle bir bağlama eşlenir.

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

## Sınırları nasıl bulabilirsiniz

- **İş yetenekleriyle hizala** (Siparişler, Faturalandırma, Kargo), isim veya veritabanı tabloları değil.
- **İçeriye yüksek uyum, sınır boyunca** gevşek bağlantı.
- **Evrensel dil** değiştiği yeri izleyin — bu genellikle bir bağlam kenarıdır.
- İlişkileri dokumentasyon yapması için bir **bağlam haritası** kullanın (upstream/downstream).

## Anti-kalıplar

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

İki hizmet bir işlemi tamamlamak için sürekli birbirini çağırırsa, sınır muhtemelen yanlıştır.

## Neden önemli

Eryken karar verilen sınırlar sonradan taşınması çok maliyetlidir, çünkü bunlar diğer ekiplerin bağlı olduğu API'lere ve veritabanlarına dönüşür.

DDD bounded contexts, bu satırları iş boyunca çizmek için size ilkeli bir yol verir, böylece hizmetler uyumlu kalır ve sürekli koordinasyon yerine bağımsız olarak gelişebilir.