كيف تحدد حدود الخدمات باستخدام 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 طريقة منهجية لرسم تلك الخطوط على طول العمل، بحيث تبقى الخدمات متماسكة ويمكنها أن تتطور بشكل مستقل بدلاً من التنسيق المستمر.