البنية القابلة للتركيب: دليل MACH و API-first

العمارة القابلة للتركيب (Composable architecture) هي طريقة لبناء أنظمة البرمجيات من مكونات مستقلة وقابلة للاستبدال، تتواصل عبر واجهات برمجة التطبيقات (APIs) بدل الاعتماد على منصة واحدة ضخمة ومتكاملة. عمليًا، هي الإطار الأوسع الذي يندرج تحته مفهوم "بلا رأس" (headless)، وترتبط أيضًا بـ تحالف MACH الذي يروّج لتقنيات المؤسسات المفتوحة والقابلة للتركيب.

جرّب Apidog اليوم

توضيح سريع أولاً

كلمة "قابل للتركيب" (composable) تظهر في أكثر من سياق. في هذا المقال سنستخدمها بمعنى هندسة البرمجيات فقط:

• العمارة القابلة للتركيب (Composable architecture): تصميم تطبيق من قدرات عمل مستقلة، يتم ربطها عبر APIs.
• البنية التحتية القابلة للتركيب (Composable infrastructure): مفهوم في مراكز البيانات يخص تجميع موارد الحوسبة والتخزين والشبكات حسب الطلب.
• قابلية التركيب في التمويل اللامركزي (DeFi composability): تركيب بروتوكولات وعقود ذكية فوق بعضها لبناء منتجات مالية جديدة.

من الآن فصاعدًا، المقصود بـ "قابل للتركيب" هو المعنى المعماري الخاص بالبرمجيات.

ماذا تعني العمارة القابلة للتركيب عمليًا؟

في النظام القابل للتركيب، لا تبني كل شيء داخل تطبيق واحد. بدلًا من ذلك، تقسم النظام إلى وحدات مستقلة، كل وحدة تمتلك وظيفة عمل واضحة، وبياناتها، ومنطقها، وواجهات API الخاصة بها.

الوحدة الأساسية هنا تسمى القدرة التجارية المجمعة أو PBC: Packaged Business Capability. تعرّف Gartner الـ PBCs بأنها قدرات قابلة للنشر بشكل مستقل، تحتوي على بيانات ومنطق وعمليات أعمال مستقلة، وتتفاعل مع التطبيقات الأخرى عبر APIs وقنوات الأحداث.

أمثلة عملية على PBCs:

• الدفع: طرق الدفع، كشف الاحتيال، الاسترداد، النزاعات.
• البحث: الفهرسة، الترتيب، معالجة الاستعلامات.
• المخزون: توفر المنتجات، الحجز، التحديثات.
• الحسابات: تسجيل الدخول، الملف الشخصي، الصلاحيات.

كل PBC يجب أن تعرض API على مستوى الأعمال، وليس مجرد جدول قاعدة بيانات داخلي. مثلًا، بدل أن يصل تطبيق آخر مباشرة إلى جدول payments، يستدعي endpoint مثل:

POST /payments
GET /payments/{paymentId}
POST /payments/{paymentId}/refunds

بهذا الأسلوب، يمكنك تبديل مزود الدفع أو إعادة بناء الخدمة داخليًا دون كسر بقية النظام، طالما بقي عقد الـ API مستقرًا.

قابل للتركيب مقابل متراص (Monolith)

في البنية المتراصة (monolith)، تكون معظم القدرات داخل تطبيق واحد وقاعدة بيانات مشتركة. هذا يجعل البداية أسرع، لكنه يجعل التغيير أصعب مع نمو النظام.

في العمارة القابلة للتركيب، يتم فصل القدرات بحيث يمكن لكل قدرة أن تتغير، تُنشر، أو تُستبدل بشكل مستقل.

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

البعد	المتراص (Monolith)	العمارة القابلة للتركيب
وحدة التغيير	التطبيق بالكامل	قدرة تجارية واحدة (PBC)
البيانات	قاعدة بيانات مشتركة	كل قدرة تمتلك بياناتها
اختيار البائع	منصة واحدة لكل شيء	أفضل أداة لكل قدرة
الواجهة الأمامية	مرتبطة بالخلفية	منفصلة ويمكن تعدد القنوات
التكامل	استدعاءات داخلية	APIs وأحداث
خطر الارتباط بالبائع	مرتفع	أقل، لأن المكونات قابلة للاستبدال

المقايضة واضحة: تحصل على مرونة أعلى، لكنك تدفع تكلفة إضافية في التكامل، المراقبة، إدارة العقود، واختبار التوافق بين الخدمات.

MACH: النموذج الذي يقصده معظم الناس

عندما تتحدث الفرق عن قابلية التركيب، فهي غالبًا تشير إلى مبادئ MACH. هذا الاختصار يعني:

• M — Microservices: بناء القدرات كخدمات صغيرة قابلة للنشر بشكل مستقل.
• A — API-first: كل وظيفة أساسية يجب أن تكون متاحة عبر API مصممة بوضوح.
• C — Cloud-native: تشغيل المكونات بطريقة مناسبة للسحابة، مع قابلية توسع وخدمات مدارة.
• H — Headless: فصل الواجهة الأمامية عن الخلفية، بحيث يمكن للويب، الجوال، الأكشاك، أو أي قناة أخرى استخدام نفس APIs.

مهم: "قابل للتركيب"، و"بلا رأس"، و"MACH" ليست مترادفات.

• Headless تعني فصل الواجهة عن الخلفية.
• MACH مجموعة مبادئ محددة لبناء أنظمة قابلة للتركيب.
• Composable architecture هي المظلة الأوسع.

لماذا API-first هي العمود الفقري؟

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

الـ API هي العقد الذي يربط المكونات المستقلة. لذلك، لا تبدأ بالتنفيذ ثم توثق لاحقًا. ابدأ بالعقد.

خطوات عملية:

1. حدد حدود كل PBC.
2. صمم API لكل قدرة قبل التنفيذ.
3. اتفق مع المستهلكين على شكل الطلبات والاستجابات.
4. أنشئ mock server حتى تستطيع الفرق العمل بالتوازي.
5. أضف اختبارات عقد في CI لضمان عدم كسر المستهلكين.
6. وثّق API كجزء من المنتج، وليس كملف جانبي.

مثال مبسط لعقد OpenAPI لقدرة "المنتجات":

openapi: 3.0.3
info:
  title: Product Catalog API
  version: 1.0.0

paths:
  /products/{id}:
    get:
      summary: Get product by ID
      parameters:
        - name: id
          in: path
          required: true
          schema:
            type: string
      responses:
        "200":
          description: Product found
          content:
            application/json:
              schema:
                type: object
                required:
                  - id
                  - name
                  - price
                properties:
                  id:
                    type: string
                  name:
                    type: string
                  price:
                    type: number

هذا العقد يصبح نقطة الاتفاق بين فريق الكتالوج، فريق الواجهة الأمامية، وفريق الدفع أو البحث.

لهذا السبب، فإن تطوير API-first ليس خيارًا ثانويًا في الأنظمة القابلة للتركيب. وإذا كانت الواجهة الأمامية بلا رأس والقدرات قابلة للتبديل، فإن واجهة برمجة التطبيقات هي المنتج الذي تستهلكه فرقك وشركاؤك.

الفوائد والمقايضات

استخدم العمارة القابلة للتركيب عندما تحتاج إلى:

• أفضل أداة لكل قدرة: مثل استخدام محرك بحث متخصص بدل وحدة ضعيفة داخل منصة شاملة.
• تغيير مستقل: تعديل خدمة الدفع دون إعادة نشر الكتالوج أو الحسابات.
• تقليل الارتباط بالبائع: لأن كل مكون يمكن استبداله خلف API مستقر.
• فرق تعمل بالتوازي: كل فريق يمتلك قدرة واضحة وينشرها بشكل مستقل.
• دعم قنوات متعددة: الويب، الجوال، نقطة البيع، الصوت، أو أي عميل آخر.

لكن انتبه للتكاليف:

• تكامل أكثر: كل مكون يحتاج اتصالًا واضحًا ومراقبة.
• انضباط في العقود: أي تغيير كاسر في API قد يعطل عدة مستهلكين.
• تشغيل أكثر تعقيدًا: تحتاج logging، tracing، authentication، rate limiting، وإدارة إصدارات.
• تصميم مسبق أكثر: يجب تحديد حدود القدرات والعقود قبل التوسع.

قاعدة عملية: إذا كان النظام صغيرًا وفريقك محدودًا، فقد يكون monolith نظيف أفضل. أما إذا كان لديك قنوات متعددة، فرق متعددة، أو حاجة حقيقية لاستبدال القدرات، فالعمارة القابلة للتركيب تصبح منطقية.

أين يتناسب Apidog: طبقة API-first

لا يجعل Apidog بنيتك قابلة للتركيب تلقائيًا. هو ليس CMS، ولا محرك تجارة إلكترونية، ولا API Gateway، ولا منصة MACH.

دوره هو دعم الحرف A في MACH: API-first.

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

استخدمه عمليًا في سيناريو قابل للتركيب كالتالي:

1. صمم العقد قبل التنفيذ
   
   عرّف API لكل PBC باستخدام OpenAPI قبل بدء كتابة الكود، حتى يتفق المستهلكون والمقدمون مبكرًا.

2. شغّل mock server
   
   إذا كان فريق الواجهة ينتظر فريق الخلفية، استخدم خوادم وهمية (Mock servers) ليبدأ العمل بناءً على العقد.

3. اختبر العقد في CI
   
   شغّل اختبارات API بدون واجهة رسومية عبر CLI، بحيث يتم كشف أي تغيير كاسر قبل الدمج.

4. وثّق API للمستهلكين
   
   في نظام يعتبر API كمنتج، التوثيق ليس خطوة أخيرة؛ هو جزء من تجربة المطور.

5. أدر المشروع من أدواتك
   
   عبر MCP، يمكنك إدارة مشروع API من وكيل ذكاء اصطناعي أو بيئة تطوير متكاملة (IDE).

إذا أردت البدء بتصميم وتهيئة عقد API قبل وجود الواجهة الخلفية، يمكنك تنزيل Apidog.

متى تعتمد العمارة القابلة للتركيب؟

فكر في اعتمادها عندما تنطبق عدة نقاط من القائمة التالية:

• تحتاج إلى خدمة قنوات متعددة من نفس منطق الأعمال.
• قدرات النظام تتغير بسرعات مختلفة جدًا.
• تريد استخدام بائعين متخصصين بدل منصة واحدة شاملة.
• الارتباط بالبائع يمثل خطرًا تجاريًا حقيقيًا.
• لديك فرق قادرة على امتلاك APIs، الاختبارات، والتشغيل طويل المدى.
• تحتاج إلى استبدال مكونات دون إعادة بناء النظام بالكامل.

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

قائمة تنفيذ مختصرة

إذا قررت البدء، اتبع هذا الترتيب:

1. ارسم خريطة القدرات التجارية

   • كتالوج
   • بحث
   • دفع
   • مخزون
   • حسابات
   • شحن

2. حدد مالكًا لكل قدرة

   • فريق أو خدمة مسؤولة عن البيانات والمنطق والعقد.

3. صمم APIs قبل الكود

   • استخدم OpenAPI.
   • اتفق على request/response schemas.
   • عرّف أخطاء موحدة.

4. امنع الوصول المباشر للبيانات

   • لا تجعل خدمة الدفع تقرأ جداول المخزون مباشرة.
   • استخدم API أو أحداثًا واضحة.

5. أضف mock servers

   • حتى تعمل الواجهة الأمامية والشركاء دون انتظار التنفيذ.

6. اختبر العقود

   • أضف اختبارات API في CI.
   • راقب التغييرات الكاسرة.

7. راقب كل خدمة

   • logs
   • metrics
   • tracing
   • alerting

8. خطط للإصدارات

   • لا تكسر المستهلكين.
   • استخدم versioning عند الحاجة.

الأسئلة الشائعة

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

لا، لكنهما يتداخلان. الخدمات المصغرة طريقة تقنية لتفكيك النظام إلى خدمات قابلة للنشر بشكل مستقل. أما العمارة القابلة للتركيب فتفكك النظام حسب القدرات التجارية، وتضيف فكرة المكونات الأفضل في فئتها والقابلة للاستبدال عبر APIs.

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

ما الفرق بين القابل للتركيب و"بلا رأس"؟

"بلا رأس" (headless) تعني فصل الواجهة الأمامية عن الخلفية، بحيث يمكن لأي عميل استهلاك نفس APIs.

أما "القابل للتركيب" فهو أوسع: بناء النظام كاملًا من قدرات مستقلة ومتصلة عبر APIs. يمكن أن تكون لديك خدمة headless واحدة دون أن يكون النظام كله قابلًا للتركيب.

ما هي القدرة التجارية المجمعة (PBC)؟

الـ PBC هي وحدة مستقلة تمتلك وظيفة عمل كاملة، بما في ذلك البيانات، المنطق، والـ APIs. أمثلة نموذجية:

• خدمة بحث
• خدمة دفع
• خدمة مخزون
• خدمة حسابات

كل واحدة تعرض API على مستوى الأعمال، ويمكن نشرها أو استبدالها بشكل مستقل.

هل أحتاج إلى منصة API لكي أصبح قابلًا للتركيب؟

تحتاج إلى طريقة منضبطة لتصميم، اختبار، وتوثيق عقود APIs. قد تكون هذه الطريقة مجموعة أدوات منفصلة أو منصة واحدة تغطي التصميم، التهيئة، الاختبار، والتوثيق.

النقطة الأساسية ليست اسم الأداة، بل استقرار العقود بين المكونات.

خلاصة

العمارة القابلة للتركيب تعني بناء النظام من قدرات مستقلة، قابلة للاستبدال، ومتصلة عبر APIs. "بلا رأس"، MACH، والخدمات المصغرة كلها مفاهيم مرتبطة، لكنها ليست الشيء نفسه.

إذا أردت تنفيذها بنجاح، ركّز على العقود أولًا. صمم APIs بوضوح، اختبرها باستمرار، ووثّقها للمستهلكين. أدوات مثل Apidog تساعدك في طبقة API-first، وهي الطبقة التي تعتمد عليها قابلية التركيب فعليًا.