DDD bounded contexts ஐப் பயன்படுத்தி சேவை எல்லைகளை எவ்வாறு வரையறுக்கிறீர்கள்?

Question

Accepted Answer

நல்ல சேவை எல்லைகள் **வணிக திறன்களை** பின்பற்றுகின்றன, தொழில்நுட்ப அடுக்குகளை அல்ல. **Domain-Driven Design (DDD)** இதற்கு ஒரு துல்லியமான கருவியை வழங்குகிறது: **bounded context** — ஒரு எல்லை, அதனுள் ஒரு டোமைன் மாதிரி மற்றும் அதன் சொற்கள் ஒருமுறை.

## Bounded context

"வாடிக்கையாளர்" என்ற சொல் வெவ்வேறு சூழ்நிலைகளில் வெவ்வேறு விஷயங்களைக் குறிக்கலாம். ஒவ்வொரு bounded context தனது சொந்த மாதிரியை소유 செய்கிறது, மற்றும் ஒரு மைக்ரோசேவை பொதுவாக ஒரு சூழ்நிலையுடன் வரைபடமாக்கப்படுகிறது.

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

## எல்லைகளை எவ்வாறு கண்டறிவது

- **வணிக திறன்களுடன் சீரமைக்கவும்** (ஆர்டர்கள், பில்லிங், ஷிப்பிং், பெயர்நிலைகள் அல்லது தரவுவிளம்பர அட்டவணைகளுடன் அல்ல.
- **உள்ளே உচ்ச ஒன்றிப்பு, முழு** எல்லைக்கு தளர்வான இணைப்பு.
- பார்க்கவும் **ubiquitous language** மாற்றங்கள் — இது பொதுவாக சூழ்நிலை விளிம்பு.
- ஒரு **context map** ஐப் பயன்படுத்தி உறவுகளை ஆவணப்படுத்தவும் (upstream/downstream).

## விரோதப் பொருட்கள்

```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 உங்களுக்கு வணிகத்தில் இந்த வரிகளை வரையெழுதும் ஒரு கொள்கை முறை வழங்கிறது, எனவே சேவைகள் ஒன்றிணைந்ததாக இருக்கின்றன மற்றும் மாறி புரிந்துகொள்ள முடியும் நிலையில் பெரும்பாலும் ஒற்றுமையாக இருக்கின்றன.