آپ DDD bounded contexts استعمال کرتے ہوئے service boundaries کو کیسے define کرتے ہیں؟

Question

Accepted Answer

اچھی service boundaries **business capabilities** کی پیروی کرتی ہیں، نہ کہ technical layers کی۔ **Domain-Driven Design (DDD)** اس کے لیے ایک واضح tool فراہم کرتی ہے: **bounded context** — ایک boundary جس کے اندر ایک domain model اور اس کی terms مستقل رہتی ہیں۔

## Bounded context

لفظ "Customer" مختلف contexts میں مختلف معنیٰ رکھ سکتا ہے۔ ہر bounded context اپنا model رکھتا ہے، اور ایک microservice عام طور پر ایک context سے map کرتا ہے۔

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

## Boundaries کو تلاش کرنا

- **Business capabilities سے align کریں** (Orders, Billing, Shipping)، nouns یا DB tables سے نہیں۔
- **High cohesion اندر، loose coupling** boundary کے پار۔
- یہ دیکھیں کہ **ubiquitous language** کہاں بدلتی ہے — یہ عام طور پر ایک context edge ہے۔
- relationships (upstream/downstream) کو document کرنے کے لیے **context map** استعمال کریں۔

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

اگر دو services ایک operation کو مکمل کرنے کے لیے ہمیشہ ایک دوسرے کو call کرتے ہیں، تو boundary شاید غلط ہے۔

## یہ کیوں اہم ہے

شروع میں فیصلہ شدہ boundaries کو بعد میں منتقل کرنا بہت مہنگا ہوتا ہے، کیونکہ وہ APIs اور databases میں سخت ہو جاتے ہیں جن پر دوسری teams منحصر ہوتی ہیں۔

DDD bounded contexts آپ کو ان لکیروں کو business کے ساتھ کھینچنے کا ایک اصول پر مبنی طریقہ دیتے ہیں، تاکہ services cohesive رہیں اور آزادانہ طور پر evolve کر سکیں بجائے مسلسل ہم آہنگی کے۔