---
title: "اتحاد الأنظمة دون دمجها"
summary: "حين تخدم عدة منتجات جماهير مختلفة فعلاً، قد يدمّر الدمج ما جعل كلاً منها جيداً. والعقود المنشورة تؤدي المهمة نفسها بخسارة أقل، مقابل كلفة تشغيلية حقيقية."
canonical: https://cpaas.co/ar/learn/federating-without-merging
kind: whitepaper
depth: advanced
origin: original
published: 2026-07-20T16:26:18.899Z
updated: 2026-10-14T16:26:19.548Z
topics: ["Architecture", "CPaaS", "Procurement"]
language: ar
---
# اتحاد الأنظمة دون دمجها

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

معظم المؤسسات التي تشتري أنظمة الاتصال أو تبنيها تنتهي بعدة أنظمة متداخلة: أداة تسويق وصندوق دعم يرسل كلاهما رسائل واتساب، ونظام إدارة عملاء ومنصة مراسلة يخزّن كلاهما جهات الاتصال، ومنتجان من استحواذ يفعلان أشياء متشابهة. والغريزة المعتادة دمجها في نظام واحد. وأحياناً يكون ذلك صواباً. وكثيراً ما يكون مكلفاً ويجعل كليهما أسوأ. تشرح هذه المادة البديل، أي ربط الأنظمة عبر واجهات منشورة ("الاتحاد")، وما يتطلبه، وما يكلّفه، واختباراً بسيطاً للاختيار بين الطريقين. وهي تنطبق بالقدر نفسه على مشترٍ يختار بين منظومة شاملة وعدة أدوات متخصصة.

## لماذا قد يدمّر الدمج القيمة

المنتجات التي تخدم جماهير مختلفة تختلف بطرق تبدو تكراراً وليست كذلك.

فأداة للمطورين وأداة لأصحاب منشآت صغيرة غير تقنيين قد ترسل كلتاهما رسائل واتساب. ودمجهما قد يُنتج منتجاً واحداً معقداً أكثر مما يحتمل الجمهور الثاني ومقيداً أكثر مما يحتمل الأول. فـ"التكرار" كان هو التكيّف مع كل جمهور.

والصيغة العامة: **حين يتشارك نظامان آليةً ولا يتشاركان مستخدماً، فالآلية عَرَض والمستخدم جوهر.** والتوحيد على الآلية يخاطر برمي الجوهر.

## الدمج أم الاتحاد أم منظومة شاملة: المقايضات

| | الدمج في نظام واحد | الاتحاد (الربط عبر واجهات منشورة) | شراء منظومة شاملة واحدة |
|---|---|---|---|
| ملاءمة فئات مستخدمين مختلفة | ضعيفة: تصميم واحد للجميع | جيدة: يحتفظ كلٌّ بتصميمه | تعتمد على اتساع المنظومة |
| اتساق البيانات | قوي: قاعدة بيانات واحدة | يحتاج انضباطاً: مالك واحد لكل واقعة | قوي داخل المنظومة |
| سرعة التغيير | أبطأ: إصدارات مشتركة | أسرع: كلٌّ ينشر وحده | يحددها مخطط المزوّد |
| الكلفة التشغيلية | أقل بعد الإنجاز | أعلى: استدعاءات شبكة وإصدارات | أقل عليك؛ تُدفع في رسوم الترخيص |
| الخروج والاستبدال | صعب: كل شيء متشابك | أسهل: استبدل جزءاً كل مرة | صعب: تنتقل المنظومة كلها معاً |
| الأنسب حين | المستخدم نفسه والعمل نفسه | مستخدمون مختلفون وعملاء مشتركون | فريق صغير واحتياجات معيارية |

لا يوجد عمود صحيح دائماً. وبقية هذه المادة عن إتقان العمود الأوسط حين يكون هو الخيار الصحيح.

## ما يتطلبه الاتحاد فعلاً

أربعة أمور، بهذا الترتيب.

```diagram:steps
# ما يتطلبه الاتحاد، بالترتيب
عقود منشورة | لا كود مشترك
هوية متسقة | من يستدعي، ونيابةً عمّن
أعراف متسقة | لا قاعدة بيانات مشتركة
اتجاه سلطة واحد لكل واقعة | مصدر حقيقة واحد بالضبط؛ والنسخ قد تتأخر
```

**1. عقود منشورة لا كود مشترك.** يعرض كل نظام واجهة موثّقة، مثل وصف OpenAPI أو مخطط أحداث (و CloudEvents أحد المعايير المفتوحة لوصف الأحداث)، ويستهلك واجهات غيره. أما المكتبات المشتركة فتُنشئ اقتراناً بمعظم كلف الدمج وقليل من فوائده، لأن أحداً لن يستطيع النشر باستقلال بعدها.

**2. هوية متسقة.** وهذا هو الصعب، والذي تتخطاه معظم الاتحادات. فالأنظمة التي يستدعي بعضها بعضاً تحتاج إثبات من هي ونيابةً عمّن تتصرف، مع أثر تدقيق وطريقة لسحب الصلاحية. وبدونه تحصل على أسرار مشتركة في ملفات إعداد، وهو دمج بوسيلة أخرى. انظر [الهوية بين الخدمات](/ar/learn/service-to-service-identity).

**3. أعراف متسقة لا قاعدة بيانات مشتركة.** اتفقوا على كيفية تعريف جهة الاتصال، وصيغة التوقيتات، وشكل الأخطاء، وطريقة توقيع الاستدعاءات (webhooks). ولا تتفقوا على مخطط واحد: فذلك دمج بقبعة مختلفة.

**4. اتجاه سلطة واحد لكل واقعة.** فلكل قطعة بيانات نظام واحد بالضبط هو مصدر الحقيقة، ويحمل الباقون نسخاً يُسمح صراحةً بأن تتأخر قليلاً. ونظامان يعتقد كلاهما أنه يملك حالة الموافقة سيتباعدان، وقد تكتشف التباعدَ جهةٌ تنظيمية.

الاتحاد ليس "دع الأنظمة وشأنها". فالأنظمة التي لا تتشارك شيئاً ليست متحدة بل منفصلة فحسب. والاتحاد مجموعة محددة من الالتزامات المنشورة، والعمل في الالتزامات لا في الكود.

```diagram:layers
# ما ينشره كل نظام، من الأسفل إلى الأعلى
بياناته | لا تُشارَك جملةً أبداً. والملكية تبقى حيث يُشغَّل النظام ويُساءل.
هوية مستقرة | شيء يستطيع نظام آخر الإشارة إليه دون معرفة كيف يُخزَّن داخلياً.
عقد منشور | الواجهة، بإصدارات وسياسة إيقاف. وهذا هو الاقتران الوحيد الموجود.
جسر هوية | كيف يقابل موضوع في نظام موضوعاً في آخر، ومن يجوز له تأكيد ذلك.
سلطة مفوَّضة | منح محدد النطاق وقابل للسحب ومحدود بمدة. نظام يعمل لآخر بإثبات.
أدلة مشتركة | أثر التدقيق العابر للحد، ليُجاب عن سؤال عبره.
> الطبقة السفلى هي ما يدمّره الدمج. والطبقات الثلاث العليا هي ما يحاول الدمج شراءه عادةً، ويمكن الحصول عليها بدونه في الغالب.
```

## نمط التفويض

الشكل الأنفع غالباً أن *يفوّض* نظام إلى آخر بدل أن يكرره.

فإن كان لمنتج بيانات اعتماد صادرة ومواصفة منشورة وموزّع استدعاءات موقّعة، ولآخر أقوى نموذج لمجال بعينه، فالجواب ليس بالضرورة نقل الكود بينهما. يستطيع الأول أن يستدعي الثاني بدل إعادة تنفيذ ما يتقنه الثاني أصلاً.

لا شيء ينتقل. ويحتفظ كلاهما بجمهوره. وتصبح القدرة متاحة عبر واجهة صُممت أصلاً لتُستدعى.

```diagram:flow
# نظام يعمل لآخر، بأمان
أثبت الهوية | لكل نظام هوية خاصة قابلة للتحقق. لا سر مشترك ولا مفتاح واجهة في ملف إعداد.
اطلب منحاً محدد النطاق | ضيقاً: هذا الإجراء وهذا الموضوع وهذه النافذة. والمنح الواسع لأن الضيق كان مزعجاً هو الثغرة.
أصدره بانتهاء صلاحية | قصير الأجل قابل للتجديد يتفوق على طويل الأجل منسي. والانتهاء هو خاصية الأمان.
اعمل واحمل الإثبات | كل إجراء تحت التفويض يسجّل أي منح أذن به.
اسحب باستقلال | سحب نظامٍ منحاً يجب ألا يقتضي تعاون الآخر، وإلا فليس سحباً.
> بلا الخطوة الخامسة عندك تكامل لا اتحاد. ولا يظهر الفرق إلا يوم تريد الفصل.
```

## كم يكلّف الاتحاد

ليس مجانياً، والصدق في كلفته مهم:

- **استدعاءات شبكة حيث كان يكفي استدعاء دالة**، بما يستتبعه من زمن استجابة وأوضاع فشل.
- **انضباط الإصدارات.** فالعقد المنشور الذي يمكنك تغييره من طرف واحد ليس عقداً. والواجهات لا تُغيَّر عصر يوم جمعة.
- **نماذج قراءة مكررة.** فكل نظام يحمل إسقاطاً لبيانات غيره، والإسقاطات تنجرف.
- **جهد مكرر.** فقد يفعل عدة أنظمة كلٌّ نسخته مما كانت خدمة مشتركة ستفعله مرة واحدة.
- **تنسيق** لكل ما يعبر الحد فعلاً.

وما تشتريه: لا تغيير منفرداً يُسقط كل شيء، ويتحرك كل منتج بوتيرته، ويحمل كلٌّ وزنه التنظيمي وحده، ويمكن استبدال أي منها أو بيعه أو إيقافه دون فكّ الآخرين.

والمقايضة مقصودة: تقبل تعقيداً تشغيلياً لتحفظ استقلال المنتجات. وهي تستحق حين تخدم المنتجات أشخاصاً مختلفين، ولا تستحق عادةً في غير ذلك. ولثلاث خدمات هي منتج واحد حقيقةً، الاتحاد عبء باسم أجمل.

```diagram:compare
| ما يكلّفه | ما يشتريه
الاستدعاءات | استدعاءات شبكة حيث كان يكفي استدعاء دالة | لا تغيير منفرداً يُسقط كل شيء
التغيير | انضباط الإصدارات: لا تغيير للعقود عصر يوم جمعة | يتحرك كل منتج بوتيرته
البيانات | نماذج قراءة مكررة تنجرف | يحمل كلٌّ وزنه التنظيمي وحده
الجهد | جهد مكرر، وتنسيق عبر الحد | يمكن استبدال أي جزء أو بيعه أو إيقافه وحده
> يستحق حين تخدم المنتجات أشخاصاً مختلفين. ولثلاث خدمات هي منتج واحد حقيقةً، هو عبء باسم أجمل.
```

## الاختبار

قبل دمج نظامين، اسأل: **هل لهما المستخدم نفسه؟**

لا المشتري نفسه. ولا المؤسسة نفسها. بل الشخص نفسه، يؤدي العمل نفسه، في اليوم نفسه.

فإن كان الجواب نعم، فالدمج صحيح عادةً: إذ يكلّفك الفصل. وإن كان لا، ففكّر في الاتحاد، وكفّ عن قياس التكرار كأنه هدر خالص.

```diagram:decision
# قبل دمج نظامين
هل لهما المستخدم نفسه — الشخص نفسه، يؤدي العمل نفسه، في اليوم نفسه؟ | الدمج صحيح عادةً: فالفصل يكلّفك | فكّر في الاتحاد، وكفّ عن عدّ التكرار هدراً خالصاً
> لا المشتري نفسه، ولا المؤسسة نفسها.
```

## الخلاصة

انشر العقود، وجسّر الهوية، وفوّض بمنح محددة النطاق قابلة للسحب، وشارك الأدلة عبر الحد. وأبقِ كل قطعة بيانات حيث تُساءل. واقبل شيئاً من التكرار ثمناً للفشل المستقل والتغيير المستقل، واسأل بصدق هل تستطيع فصل نظام واحد غداً.

## إلى أين بعد ذلك

- [الثغرة التي لا يملؤها أحد: الهوية بين الخدمات](/ar/learn/service-to-service-identity): طبقة الهوية التي يعتمد عليها الاتحاد.
- [تقييم عقد منصة اتصال](/ar/learn/evaluating-a-cpaas-contract): بنود الخروج وقابلية النقل التي تحدد هل المزوّد جزء يمكنك استبداله.

## Sources

[^1]: [OpenAPI Specification](https://spec.openapis.org/oas/latest.html) — OpenAPI Initiative
[^2]: [CloudEvents](https://cloudevents.io/) — Cloud Native Computing Foundation
[^3]: [Standard Webhooks](https://www.standardwebhooks.com/) — Standard Webhooks
[^4]: [Bounded Context](https://martinfowler.com/bliki/BoundedContext.html) — martinfowler.com
[^5]: [RFC 8693: OAuth 2.0 Token Exchange](https://www.rfc-editor.org/rfc/rfc8693) — IETF

---

Published by the company behind five products in this category. Those products appear in this site's directory alongside competitors under the same published criteria and are labelled as its own. Editorial content does not recommend them.