DDD bounded contexts वापरून सेवा सीमा (service boundaries) कसे परिभाषित करता येतात?

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), संज्ञा किंवा डेटाबेस टेबलांशी नाही.
- **सीमेच्या अंदरून उच्च सुसंगतता, बाहेरून सैल जोडणी**.
- जिथे **ubiquitous language** बदलते तेथे लक्ष रागा — सामान्यत: तेथे संदर्भ किनारा असतो.
- संबंध (upstream/downstream) दस्तऐवज करण्यासाठी **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
```

जर दोन सेवा एक ऑपरेशन पूर्ण करण्यासाठी सतत एकमेकांना कॉल करत असतील, तर सीमा कदाचित चुकीची आहे.

## हे महत्वाचे का आहे

लवकर निर्णय घेतलेल्या सीमा नंतर हलविण्यासाठी अत्यंत महाग असतात, कारण ते APIs आणि डेटाबेसमध्ये कठिण होतात ज्यांवर इतर टीम आश्रित असतात.

DDD bounded contexts आपल्याला व्यावसायिकतेच्या बाजूने हे रेषा काढण्याचा एक तत्त्वनिष्ठ मार्ग देतात, जेणेकरून सेवा सुसंगत राहतात आणि सतत समन्वयाऐवजी स्वतंत्रपणे विकसित होऊ शकतात.