আপনি কীভাবে DDD bounded contexts ব্যবহার করে সেবার সীমানা সংজ্ঞায়িত করেন?

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** পরিবর্তিত হয় — যা সাধারণত একটি প্রসঙ্গ প্রান্ত।
- সম্পর্ক নথিভুক্ত করতে একটি **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
```

যদি দুটি সেবা একটি অপারেশন সম্পূর্ণ করতে ক্রমাগত একে অপরকে কল করে, তাহলে সীমানা সম্ভবত ভুল।

## কেন এটি গুরুত্বপূর্ণ

আগাম নির্ধারিত সীমানা পরে সরানো অত্যন্ত ব্যয়বহুল, কারণ তারা APIs এবং ডাটাবেসে কঠোর হয়ে ওঠে যা অন্য দল নির্ভর করে।

DDD bounded contexts আপনাকে ব্যবসা জুড়ে সেই লাইনগুলি আঁকার একটি নীতিগত উপায় দেয়, যাতে সেবাগুলি সংযুক্ত থাকে এবং ক্রমাগত সমন্বয় করার পরিবর্তে স্বাধীনভাবে বিকশিত হতে পারে।