तपाईं DDD bounded contexts प्रयोग गरेर सेवा सीमाहरू कसरी परिभाषित गर्नुहुन्छ?

Question

Accepted Answer

राम्रो सेवा सीमाहरू **व्यावसायिक क्षमताहरू**, तकनीकी स्तरहरू नभई पछ्याउँछन्। **Domain-Driven Design (DDD)** यसको लागि एक सटीक उपकरण दिन्छ: **bounded context** — एक सीमा जस भित्र एक डोमेन मडेल र यसका सर्तहरू सुसंगत छन्।

## Bounded context

"Customer" शब्दको विभिन्न सन्दर्भहरूमा विभिन्न अर्थ हुन सक्छ। प्रत्येक bounded context आफ्नो मडेल राख्छ, र एक माइक्रोसेवा सामान्यतः एक सन्दर्भमा म्याप गरिन्छ।

```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 ले तपाईंलाई यो व्यावसायिक रेखाहरूको साथ खिच्नको लागि एक सैद्धान्तिक तरिका दिन्छ, ताकि सेवाहरू सुसंगत रहन्छन् र लगातार समन्वय गर्नुको बजाय स्वतन्त्र रूपमा विकास गर्न सक्छन्।