તમે DDD બાઉન્ડેડ કોન્ટેક્સ્ટનો ઉપયોગ કરીને સેવાની સીમાઓ કેવી રીતે વ્યાખ્યાયિત કરો છો?

Question

Accepted Answer

સારી સેવાની સીમાઓ **વ્યવસાયિક ક્ષમતાઓ** અનુસરે છે, તકનીકી સ્તરો નહીં. **Domain-Driven Design (DDD)** આ માટે એક સચોટ સાધન આપે છે: **બાઉન્ડેડ કોન્ટેક્સ્ટ** — એક સીમા જેમાં ડોમેન મોડલ અને તેની શર્તો સુસંગત છે.

## બાઉન્ડેડ કોન્ટેક્સ્ટ

શબ્દ "Customer" વિવિધ સંદર્ભોમાં વિવિધ અર્થો આપી શકે છે. દરેક બાઉન્ડેડ કોન્ટેક્સ્ટ પોતાનું મોડલ માલિક છે, અને માઇક્રોસર્વિસ સામાન્ય રીતે એક સંદર્ભમાં મેપ કરે છે.

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

## સીમાઓ કેવી રીતે શોધો

- **વ્યવસાયિક ક્ષમતાઓ** (ઓર્ડર્સ, બિલિંગ, શિપિંગ) માટે સરিસૃપ કરો, સંજ્ઞા અથવા DB ટેબલ નહીં.
- **સીમાની અંદર ઉચ્ચ સમન્વય, સમગ્ર પર ढીલો કપલિંગ**.
- જ્યાં **સર્વત્ર ભાષા** બદલાય છે તે જુઓ — તે સામાન્ય રીતે સંદર્ભ ધાર છે.
- **સંદર્ભ નક્શો** ઉપયોગ કરો સંબંધો (ઉપસ્ટ્રીમ/ડાઉનસ્ટ્રીમ) દસ્તાવેજ કરવા માટે.

## ખરાબ પદ્ધતિઓ

```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 બાઉન્ડેડ કોન્ટેક્સ્ટ તમને વ્યવસાય સાથે આ રેખાઓ આકર્ષણ કરવાની સિદ્ધાંતપૂર્ણ રીત આપે છે, જેથી સેવાઓ સમન્વયી રહે અને સતત સંકલન કરવાને બદલે સ્વતંત્ર રીતે વિકાસ કરી શકે.