كيف تدير البيانات عندما يكون لكل خدمة قاعدة بيانات خاصة بها؟

Question

Accepted Answer

بدون **قاعدة بيانات مشتركة**، لا يمكنك استخدام `JOIN` بين الخدمات أو معاملات ACID واحدة. تقوم بتكوين البيانات والحفاظ على اتساقها باستخدام **API composition** و**read models للـ CQRS/replication** و**events**.

## قراءة البيانات عبر الخدمات

**API composition** — منسق يستدعي كل خدمة ويجمع النتيجة:

```js
// build an order view from three services
const order    = await ordersApi.get(orderId);
const customer = await usersApi.get(order.customerId);   // separate service
const shipment = await shippingApi.get(orderId);
return { ...order, customer, shipment }; // composed in memory
```

للاستعلامات الثقيلة، احتفظ بـ **read model** (CQRS): تشترك الخدمة في الأحداث وتبني نسخة محلية غير مُطبّعة يمكنها الاستعلام عنها مباشرة.

```text
Orders ─event→ ┐
Users  ─event→ ├─▶ [ Order-View service builds its own queryable table ]
Shipping ─event→ ┘
```

## الكتابة عبر الخدمات

استخدم نمط **Saga** — سلسلة من المعاملات المحلية مع إجراءات تعويضية — بدلاً من معاملة موزعة.

## المفاضلات

| الأسلوب | الإيجابيات | السلبيات |
|---|---|---|
| API composition | بيانات طازجة دائماً | الكمون، التوسيع، هش |
| Replicated read model | قراءة سريعة | اتساق في النهاية |
| Saga | لا يوجد 2PC مطلوب | معقد، يحتاج تعويض |

## فخ شائع

لا تقم بـ "مجرد" مشاركة جدول لتسهيل الربط — فهذا يعيد ربط الخدمات. اقبل الاتساق في النهاية حيث يسمح به العمل.

## لماذا يهم هذا

إدارة البيانات هي المكان الذي تصبح فيه الخدمات الصغيرة صعبة حقاً، لأن الأدوات السهلة (`JOIN`، المعاملات) اختفت بالتصميم.

فهم `API composition` و`read models` و`sagas` هو ما يسمح لك بالحفاظ على استقلالية الخدمات دون فقدان الصحة.

الأسلوب	الإيجابيات	السلبيات
API composition	بيانات طازجة دائماً	الكمون، التوسيع، هش
Replicated read model	قراءة سريعة	اتساق في النهاية
Saga	لا يوجد 2PC مطلوب	معقد، يحتاج تعويض