العمارة القابلة للتركيب (Composable architecture) هي طريقة لبناء أنظمة البرمجيات من مكونات مستقلة وقابلة للتبديل، تعتبر الأفضل في فئتها وتتواصل مع بعضها البعض من خلال واجهات برمجة التطبيقات (APIs)، بدلاً من منصة واحدة كبيرة ومتكاملة. إنها الفكرة الأوسع التي يندرج تحتها مفهوم "بلا رأس" (headless)، وترتبط ارتباطًا وثيقًا بـ تحالف MACH، وهو الهيئة الصناعية المحايدة للبائعين التي تروج لتكنولوجيا المؤسسات المفتوحة والقابلة للتركيب.
توضيح سريع أولاً
تظهر كلمة "قابل للتركيب" (composable) في ثلاثة سياقات مختلفة جدًا. دعنا نوضحها الآن لكي يصبح بقية هذا الدليل مفهومًا.
- العمارة القابلة للتركيب (Composable architecture) (هذا المقال) هي منهجية لتصميم البرمجيات. تقوم بتجميع تطبيق من مكونات عمل منفصلة، كل منها مدمج عبر واجهات برمجة التطبيقات (APIs).
- البنية التحتية القابلة للتركيب (Composable infrastructure) هي مفهوم للأجهزة ومراكز البيانات. يتم تجميع موارد الحوسبة والتخزين والشبكات وتخصيصها للأعباء العاملة حسب الطلب. وهي تعمل تحت نظام التشغيل، وليس في كود تطبيقك.
- قابلية التركيب في التمويل اللامركزي (DeFi composability) هي فكرة في البلوك تشين، وغالبًا ما يطلق عليها "مكعبات المال". تتراكم العقود الذكية مثل بروتوكولات الإقراض والتبادل فوق بعضها البعض لإنشاء منتجات مالية جديدة.
نفس الكلمة الجذرية، ولكن بثلاث طبقات غير مرتبطة. من الآن فصاعدًا، تعني "قابل للتركيب" (composable) المعنى المتعلق بهندسة البرمجيات.
ماذا تعني العمارة القابلة للتركيب فعليًا
يتم بناء النظام القابل للتركيب من وحدات معيارية ومستقلة، يمتلك كل منها وظيفة عمل كاملة. تختار أفضل أداة لكل مهمة، وتربطها عبر واجهات برمجة التطبيقات (APIs)، ويمكنك تبديل أي منها لاحقًا دون إعادة بناء كل ما حولها.
وحدة التركيب لها اسم: القدرة التجارية المجمعة (packaged business capability)، أو PBC. تُعرّف جارتنر (Gartner) القدرات التجارية المجمعة (PBCs) بأنها قدرات قابلة للنشر بشكل مستقل تتضمن بيانات عمل ومنطق وعمليات مستقلة، وتتفاعل مع التطبيقات الأخرى عبر واجهات برمجة التطبيقات وقنوات الأحداث.
فكر في القدرة التجارية المجمعة (PBC) ككل مجال عمل في صندوق. تمتلك PBC "الدفع" طرق الدفع، وفحوصات الاحتيال، والمبالغ المستردة، والنزاعات. تمتلك PBC "البحث" الفهرسة، والترتيب، ومعالجة الاستعلامات. كل واحدة منها تعرض واجهة برمجة تطبيقات على مستوى الأعمال، وليست جدول قاعدة بيانات خامًا، ويمكنك الحصول عليها من بائع أو بنائها بنفسك. تقوم بتجميع منتجك من هذه الكتل بالطريقة التي تركب بها أجزاء مجموعة.
قابل للتركيب مقابل متراص (Monolith)
تجمع بنية المتراص (monolith) كل القدرات في تطبيق واحد قابل للنشر مع قاعدة بيانات مشتركة. هذا سهل للبدء به ويصبح أصعب في التغيير مع نموه. تفصل العمارة القابلة للتركيب هذه القدرات بحيث يمكن لكل منها أن يتطور بمفرده. إذا كنت قد قرأت عن الانقسام بين المتراص والخدمات المصغرة (microservices)، فإن القابلة للتركيب هي تأطير القدرات التجارية لنفس التحول: الخدمات المصغرة هي تفكيك تقني، والقدرات التجارية المجمعة (PBCs) هي تفكيك على مستوى مجال الأعمال.
إليك التباين في لمحة سريعة.
| البعد | المتراص (Monolith) | العمارة القابلة للتركيب (Composable architecture) |
|---|---|---|
| وحدة التغيير | التطبيق بأكمله | قدرة تجارية مجمعة واحدة (PBC) |
| البيانات | قاعدة بيانات مشتركة واحدة | كل قدرة تمتلك بياناتها الخاصة |
| اختيار البائع | منصة واحدة، خذ كل شيء | الأفضل في فئته لكل قدرة |
| الواجهة الأمامية (Front end) | مرتبطة بالواجهة الخلفية (back end) | غير مرتبطة، أي عدد من القنوات |
| التكامل | استدعاءات وظيفية داخلية | واجهات برمجة التطبيقات (APIs) والأحداث |
| خطر الارتباط بالبائع (lock-in) | عالي | أقل، المكونات قابلة للاستبدال |
المقايضة حقيقية. توفر لك العمارة القابلة للتركيب المرونة وقابلية الاستبدال. كما أنها تمنحك المزيد من الأجزاء المتحركة للتكامل والمراقبة والحفاظ عليها ضمن العقود.
MACH: المعيار الذي يقصده معظم الناس
عندما تتحدث الفرق عن "قابلية التركيب"، فإنها عادة ما تعني مجموعة تقنيات تتبع مبادئ MACH. MACH هو اختصار، ويروج تحالف MACH (الذي تأسس عام 2020) له كبنية معمارية للأنظمة المفتوحة والقابلة للتركيب.
- M، الخدمات المصغرة (Microservices). يتم بناء القدرات كخدمات صغيرة قابلة للنشر بشكل مستقل بدلاً من كتلة واحدة.
- A، منهجية API-first. يتم عرض كل وظيفة من خلال واجهة برمجة تطبيقات (API). واجهة المستخدم (UI) هي مجرد مستهلك واحد لتلك الواجهة، وليست الطريقة الوحيدة للوصول.
- C، سحابية المنشأ (Cloud-native). يتم بناء المكونات للسحابة، باستخدام التوسع المرن والخدمات المدارة.
- H، بلا رأس (Headless). يتم فصل الواجهة الأمامية عن الواجهة الخلفية، بحيث يمكنك النشر إلى الويب، الجوال، الأكشاك، أو أي شيء آخر من نفس واجهات برمجة التطبيقات.
لاحظ أن "القابلة للتركيب" (composable)، و"بلا رأس" (headless)، و"MACH" ليست مترادفات. "بلا رأس" هي حرف واحد من MACH. وMACH هي طريقة محددة وذات رأي لبناء أنظمة قابلة للتركيب. أما "القابلة للتركيب" فهي المظلة التي تشمل كل ذلك.
العمود الفقري لمنهجية API-first
إذا تعمقت في أي من هذه الخيوط، ستصل إلى نفس النقطة: واجهة برمجة التطبيقات (API) هي طبقة التكامل التي تجمع النظام القابل للتركيب. إذا كانت المكونات مستقلة ويمتلك كل منها بياناته الخاصة، فإن الشيء الوحيد الذي يربطها هو العقد بينها.
لهذا السبب، فإن تطوير API-first هو الركيزة غير القابلة للتفاوض. في المتراص (monolith)، يمكن لوحدتين الوصول إلى نفس قاعدة البيانات واستدعاء وظائف بعضهما البعض مباشرة. في نظام قابل للتركيب، يختفي هذا الاختصار. ولا تكون القدرة مفيدة إلا بقدر واجهة برمجة التطبيقات التي تعرضها، ولا يكون النظام مستقرًا إلا بقدر استقرار العقود بين أجزائه.
هذه هي اللحظة أيضًا التي تتوقف فيها واجهة برمجة التطبيقات عن كونها بابًا جانبيًا وتصبح المنتج نفسه. عندما تكون الواجهة الأمامية بلا رأس (headless) والقدرات قابلة للتبديل، فإن واجهة برمجة التطبيقات هي المنتج الذي تستهلكه فرقك وشركاؤك الآخرون فعليًا. صممها بإهمال وسيؤثر ذلك على كل مستهلك تالٍ.
الفوائد والمقايضات
باختصار، حجة العمارة القابلة للتركيب هي كالتالي:
- الأفضل في فئته. استخدم أقوى أداة لكل قدرة بدلاً من الاكتفاء بأضعف وحدة لدى بائع واحد.
- تغيير مستقل. استبدل أو قم بترقية قدرة تجارية مجمعة (PBC) واحدة دون المساس بالبقية.
- تقليل الارتباط بالبائع (lock-in). المكونات القابلة للتبديل تعني أنك لست مرتبطًا بمنصة واحدة.
- فرق متوازية. تتيح القدرات المفككة للفرق النشر وفقًا لجداولها الزمنية الخاصة.
- متعدد القنوات. تتيح الواجهات الأمامية "بلا رأس" لمجموعة واحدة من واجهات برمجة التطبيقات خدمة العديد من الواجهات.
والتكاليف الصريحة هي:
- العبء الزائد للتكامل. المزيد من المكونات يعني المزيد من الاتصالات للربط والمراقبة.
- الانضباط في العقود. قد يؤدي تغيير كاسر في واجهة برمجة تطبيقات واحدة إلى تداعيات على كل ما يستدعيها.
- التعقيد التشغيلي. تمتد المراقبة والمصادقة وإدارة الإصدارات عبر العديد من الخدمات، وليس خدمة واحدة.
- التصميم المسبق. تقضي وقتًا أطول في تحديد الحدود والعقود قبل النشر.
تعتبر العمارة القابلة للتركيب مناسبة بقوة عندما تحتاج إلى المرونة، قابلية التوسع، وقنوات متعددة. ولكنها قد تكون مبالغة عندما يكفي نظامًا متراصًا (monolith) واحدًا مبنيًا بشكل جيد.
أين يتناسب Apidog: ركيزة API-first
لا يجعل Apidog بنيتك قابلة للتركيب. إنه ليس نظام إدارة محتوى (CMS)، ولا محرك تجارة إلكترونية، ولا بوابة API، ولا منصة MACH، ولن يحل محل أي منها. ما يفعله هو امتلاك "A" في MACH، وهي ركيزة API-first، وهي الطبقة التي يعتمد عليها كل شيء آخر في نظام قابل للتركيب.
نظرًا لأن واجهة برمجة التطبيقات (API) هي الواجهة الوحيدة بين مكوناتك المستقلة، يجب أن يكون العقد صحيحًا. Apidog هو المكان الذي تقوم فيه بتصميم واختبار وتهيئة وتوثيق هذا العقد:
- عقود تصميم-أولًا. حدد واجهة برمجة التطبيقات (API) لكل قدرة كعقد OpenAPI قبل أن يكتب أي شخص التنفيذ، بحيث يتفق المستهلكون والمقدمون على الشكل مقدمًا.
- خوادم وهمية (Mock servers). لا ينبغي أن تضطر الفرق المفككة إلى انتظار بعضها البعض. يتيح الخادم الوهمي لواجهة أمامية أو شريك البناء بناءً على العقد بينما لا تزال القدرة التجارية المجمعة (PBC) الخلفية قيد الإنشاء.
- تنفيذ الاختبار بلا رأس (Headless test execution). يقوم واجهة سطر الأوامر (CLI) الخاصة بـ Apidog بتشغيل اختبارات واجهة برمجة التطبيقات الخاصة بك بدون واجهة رسومية، مباشرة في التكامل المستمر (CI). وهذا يتناسب مفهوميًا مع "بلا رأس"، حيث يتم تشغيل الاختبارات بناءً على العقد، وليس من خلال شاشة.
- الإدارة من أدواتك. من خلال MCP، يمكنك إدارة مشروع واجهة برمجة التطبيقات الخاص بك من وكيل ذكاء اصطناعي أو بيئة تطوير متكاملة (IDE).
إذا كان نظامك يتبع نموذج API كمنتج، فهذه هي طبقة الجودة التي تحافظ على صدق العقود. قم بتنزيل Apidog لتصميم وتهيئة عقد قبل وجود الواجهة الخلفية.
متى يجب اعتماد العمارة القابلة للتركيب
الجأ إلى العمارة القابلة للتركيب عندما يكون أكثر من واحد مما يلي صحيحًا:
- تحتاج إلى خدمة قنوات متعددة (الويب، الجوال، في المتجر، الصوت) من منطق مشترك.
- تتغير القدرات المختلفة بمعدلات متباينة جدًا، وقد سئمت من إعادة نشر كل شيء لإصلاح صغير.
- تريد بائعين هم الأفضل في فئتهم لكل قدرة بدلاً من مجموعة واحدة.
- الارتباط بالبائع (vendor lock-in) يمثل خطرًا تجاريًا حقيقيًا بالنسبة لك.
- لديك الفريق والانضباط اللازمين لامتلاك عقود واجهات برمجة التطبيقات (API) والتكامل على المدى الطويل.
إذا كنت فريقًا صغيرًا يقوم بشحن منتج واحد بجدول زمني ضيق، فإن نظامًا متراصًا (monolith) نظيفًا غالبًا ما يكون الخيار الأذكى. تكتسب العمارة القابلة للتركيب تعقيدها عند التوسع.
الأسئلة الشائعة
هل العمارة القابلة للتركيب هي نفسها الخدمات المصغرة (microservices)؟
لا، لكنهما يتداخلان. الخدمات المصغرة هي طريقة تقنية لتفكيك النظام إلى خدمات صغيرة قابلة للنشر. أما العمارة القابلة للتركيب فتفكك النظام على طول القدرات التجارية (PBCs) وتضيف فكرة المكونات الأفضل في فئتها والقابلة للتبديل المتصلة عبر واجهات برمجة التطبيقات (APIs). عادة ما تكون الخدمات المصغرة هي الطريقة التي تبني بها الواجهة الخلفية لنظام قابل للتركيب. للاطلاع على التقسيم الأوسع، راجع المتراص مقابل الخدمات المصغرة.
ما الفرق بين القابل للتركيب (composable) وبلا رأس (headless)؟
تعني "بلا رأس" (headless) أن الواجهة الأمامية مفصولة عن الواجهة الخلفية، بحيث يمكن لأي عميل استهلاك نفس واجهات برمجة التطبيقات (APIs). "القابلة للتركيب" (composable) هي المنهجية الأوسع: تجميع نظام كامل من قدرات مستقلة ومتصلة بواجهات برمجة التطبيقات. "بلا رأس" هي مبدأ واحد (الحرف "H" في MACH) تميل الأنظمة القابلة للتركيب إلى اتباعه. يمكنك أن تكون "بلا رأس" في قدرة واحدة دون أن تكون قابلاً للتركيب بالكامل عبر المكدس التقني.
ما هي القدرة التجارية المجمعة (PBC)؟
القدرة التجارية المجمعة (PBC) هي وحدة مستقلة بذاتها تمتلك وظيفة عمل كاملة، بما في ذلك بياناتها ومنطقها وواجهات برمجة التطبيقات (APIs) الخاصة بها. تصف جارتنر (Gartner) القدرات التجارية المجمعة (PBCs) بأنها قدرات قابلة للنشر بشكل مستقل تتفاعل مع التطبيقات الأخرى عبر واجهات برمجة التطبيقات وقنوات الأحداث. مكون "بحث" أو "دفع" أو "مخزون"، كل منها يعرض واجهة برمجة تطبيقات على مستوى الأعمال، هو مثال نموذجي للقدرة التجارية المجمعة.
هل أحتاج إلى منصة واجهات برمجة تطبيقات (API) لكي أصبح قابلاً للتركيب؟
تحتاج إلى طريقة لتصميم واختبار والحفاظ على استقرار عقود واجهات برمجة التطبيقات الخاصة بك، لأن تلك العقود هي الشيء الوحيد الذي يربط المكونات المستقلة معًا. يمكن أن يكون ذلك مجموعة من الأدوات المنفصلة أو منصة واحدة تغطي التصميم والتهيئة والاختبار والتوثيق في مكان واحد. النقطة الأساسية هي الانضباط في العقود، وليس أي منتج معين.
خلاصة
العمارة القابلة للتركيب (Composable architecture) هي الجنس، و"بلا رأس" (headless)، وMACH، والخدمات المصغرة (microservices) هي أنواع ضمن هذا الجنس. الفكرة الأساسية بسيطة: قدرات مستقلة، اختيار الأفضل في فئته، وواجهات برمجة التطبيقات (APIs) كنسيج رابط. هذا الجزء الأخير هو حيث تكمن معظم المخاطر، لأن العقد هو النظام. قم بتصميم واجهات برمجة التطبيقات وتهيئتها واختبارها وتوثيقها بشكل صحيح باستخدام أداة مثل Apidog، وبقية وعود العمارة القابلة للتركيب (قابلة للتبديل، متعددة القنوات، خالية من الارتباط بالبائع) سيكون لها أساس قوي تستند إليه.