ਤੁਸੀਂ 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), ਸੰਜਨਾ ਜਾਂ ਡੀਬੀ ਟੇਬਲਾਂ ਨਹੀਂ।
- **ਅੰਦਰ ਉੱਚ ਤਾਲਮੇਲ, ਪਾਰ** ਸੀਮਾ ਢਿੱਲੀ ਜੋੜ।
- ਧਿਆਨ ਦਿਓ ਜਿੱਥੇ **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 ਤੁਹਾਨੂੰ ਇਹਨਾਂ ਲਾਈਨਾਂ ਨੂੰ ਕਾਰੋਬਾਰ ਦੇ ਨਾਲ ਖਿੱਚਣ ਦਾ ਇੱਕ ਸੰਤੁਲਿਤ ਤਰੀਕਾ ਦਿੰਦਾ ਹੈ, ਤਾਂ ਜੋ ਸੇਵਾਵਾਂ ਇਕਜੁੱਟ ਰਹਿਣ ਅਤੇ ਲਗਾਤਾਰ ਤਾਲਮੇਲ ਕਰਨ ਦੀ ਬਜਾਏ ਸੁਤੰਤਰ ਰੂਪ ਵਿੱਚ ਵਿਕਸਤ ਹੋ ਸਕਣ।