الاتساق ليس هدفاً تصل إليه، بل هو اشتراك تدفعه. تكتشف كل منظمة هندسية هذا الأمر في نهاية المطاف، عادةً عندما يبدأ الفريق الثاني أو الثالث في الالتزام بنفس المستودع (repository). وسواء كنت تدير كتلة برمجية واحدة (monolith) مبنية بـ React أو مجموعة من الواجهات الأمامية القابلة للنشر بشكل مستقل، فأنت لا تسعى لتحقيق تكلفة صفرية، بل أنت ببساطة تختار أي فاتورة ستظهر لك كل ربع سنة.

ضريبة التنسيق في الأنظمة الموحدة (Monoliths)

في البنية الموحدة (monolithic architecture)، تُكتب الفاتورة بساعات العمل البشرية. تقضي الفرق أيامها في التوافق على الكود المشترك، والأنماط (styles)، وجداول الإصدارات. المطور الذي يريد إجراء إصلاح بسيط في عملية الدفع (checkout) قد يحتاج إلى تحديث تبعية مشتركة (shared dependency) تستخدمها ستة فرق أخرى، ثم ينتظر حتى تنتهي مجموعة اختبارات التراجع (regression suite) الكاملة. تتراكم التكلفة بهدوء؛ فهي لا تظهر أبداً كبند في فاتورة السحابة، بل تختبئ في انخفاض سرعة الإنجاز، وفي تبديل المهندسين لسياق عملهم (context-switching) بين محادثات Slack حول نمط الكود، وفي الاحتكاك البطيء لبنية CSS لا يملكها أحد ولكن يلمسها الجميع.

ومع نمو فريقك، تنمو هذه الضريبة معه. تتحول اختناقات مراجعة الكود من مخاوف تقنية إلى مخاوف اجتماعية. المستودع الواحد الذي يضم مائتي مساهم لا يتوسع بشكل خطي، بل يتوسع بشكل توافقي (combinatorially). تتراكم طوابير الدمج (merge queues)، وتتمدد قطارات الإصدارات (release trains) عبر أيام. يصبح نظام التصميم (design system) كياناً سياسياً يتطلب مجلساً حاكماً للموافقة على أي شكل جديد للزر. لا تقاوم الأنظمة الموحدة التغيير بدافع الخبث، بل تقاومه لأن كل سطح برمجي مشترك، وكل تغيير يتطلب إجماعاً.

رسم الحدود

تنقل الواجهات الأمامية المصغرة (Microfrontends) تكاليف التنسيق إلى حدود محددة. بدلاً من عقد اجتماع أسبوعي حول إدارة الحالة المشتركة (shared state management)، تقوم برسم خط فاصل. الفريق (أ) يمتلك كتالوج المنتجات، والفريق (ب) يمتلك عربة التسوق. يتفق الفريقان على عقد (contract)، عادة ما يكون حدود توجيه (routing boundary) أو مخطط أحداث (event schema) ضيق، ثم يتوقفان عن الحديث. هذه هي المقايضة الأساسية: الاستقلالية مقابل نوع مختلف من الانضباط.

النظرية تبدو واضحة. إذا قام فريق الشحن (Shipping team) بإعادة هيكلة طبقة التوجيه (routing layer) الخاصة به، فلا ينبغي لفريق الفواتير (Billing team) أن يهتم. وإذا احتاجت واجهة البحث إلى النشر خمس مرات يومياً، فلا ينبغي لها أن تنتظر صفحة إعدادات الحساب حتى تنهي اختبارات النهاية إلى النهاية (end-to-end tests) الخاصة بها. تحول الحدود الاحتكاك التنظيمي إلى واجهات تقنية. لكن رسم هذا الخط ليس مجانياً أبداً.

فاتورة البنية التحتية

تخلق الواجهات الأمامية المصغرة تكاليف للمنصة. فأنت بحاجة إلى تطبيق غلاف (shell application) قادر على تجميع الأجزاء في وقت التشغيل (runtime). وتحتاج إلى خط أنابيب نشر (deployment pipeline) يفهم كيفية تجميع المخرجات (artifacts) من مهام بناء متعددة في صفحة واحدة متماسكة. إذا كنت تستخدم Webpack Module Federation، فأنت الآن تدير إصدارات التبعيات المشتركة عبر حزم (bundles) مبنية بشكل مستقل. وإذا كنت تستخدم iframes، فأنت تقوم بتصحيح أخطاء المراسلة عبر الأصول (cross-origin messaging) وتصارع إزاحات التخطيط (layout shifts). وإذا كنت تستخدم web components، فأنت تقوم بإدارة إصدارات العناصر المخصصة في رسم بياني موزع (distributed graph) حيث يمكن لترقية فريق واحد أن تطغى على ترقية فريق آخر.

هذه التكاليف ملموسة ومتكررة. أنت تدفع مقابل تنسيق عملية البناء (build orchestration) التي يمكنها إصدار ست واجهات أمامية دون كسر السابعة. وتدفع مقابل القابلية للملاحظة (observability) التي تتبع إجراء المستخدم عبر ثلاث حزم JavaScript منفصلة يملكها ثلاثة فرق منفصلة. وتدفع مقابل حوكمة الأداء لأن قيام ستة فرق بتجميع نسخهم الخاصة من مكتبات الأدوات المساعدة (utility libraries) سيحول صفحتك إلى عبء ثقيل ما لم يقم شخص ما ببناء وصيانة استراتيجية لإزالة التكرار (deduplication strategy). عند هذه النقطة، ستكون قد أعدت إنشاء جزء من النظام الموحد الذي كنت تحاول الهروب منه، إلا أنه يتطلب الآن فريق منصة (platform team) لصيانته.

عندما تتحول التكاليف

تخيل شركة SaaS متوسطة الحجم لديها أربعة فرق واجهة أمامية تشترك في تطبيق Next.js واحد. تتم عمليات النشر مرتين يومياً بعد تشغيل التكامل المستمر (CI run) لمدة ثلاث ساعات. عندما يريد فريق الشحن إعادة هيكلة التنقل (navigation)، يقومون بتقديم طلب تعليقات (request for comments)، وتحديث مسارات الاستيراد (import paths) عبر الشجرة، ثم ينتظرون أسبوعين حتى يقوم فريق الفواتير بتعديل اختبارات التكامل (integration tests) الخاصة به. التكلفة هي التنسيق، بكل بساطة.

ثم ينقسمون إلى واجهات أمامية مصغرة (microfrontends). الآن يمتلك كل فريق قسماً رأسياً (vertical) ويقوم بالدفع إلى الإنتاج وفقاً لجدوله الخاص. يبدو الشهر الأول وكأنه حرية. ثم يظهر خطأ ما. تفشل الترويسة العامة (global header) في الظهور في متصفح Safari لأن فريق الشحن قام بترقية مكتبة CSS-in-JS تتعارض مع الأنماط الأساسية التي حقنها فريق البحث. يتطلب تصحيح الخطأ ثلاثة مهندسين في حالة الاستدعاء (on-call)، وغرفة عمليات (war room) مشتركة، وعملية تراجع (rollback) مؤلمة لخدمتين لأن تطبيق الغلاف (shell app) يقوم بتخزين قوائم تعريف الوحدات (module manifests) مؤقتاً. لقد انتقلت التكلفة، لكنها لم تختفِ.

حسابات التوسع

لا يوجد نموذج منهما مجاني. فالشركة الناشئة المكونة من خمسة عشر شخصًا لا تحتاج إلى فريق منصة. إن الأعباء الإضافية لـ module federation، وأنابيب النشر المستقلة، واختبار العقود الموزع ستلتهم كامل سرعة إنجازهم. يجب عليهم الدفع من خلال التنسيق لأن التنسيق رخيص؛ إذ يمكنهم الاتفاق على نمط إدارة الحالة في محادثة مدتها عشر دقائق وشحنه في نفس الظهيرة.

أما المؤسسة الكبرى المكونة من خمسمائة شخص والتي تضم عشرات وحدات الأعمال التي تعمل وفق دورات ربع سنوية مختلفة، فتواجه المشكلة المعاكسة. لقد أصبحت ضريبة التنسيق أسية، وتستغرق دورات الإصدار (Release trains) أسابيع. كما أن عدد موظفي هندسة المنصات هو بالفعل واقع ميزانية قائم، لذا فإن إضافة بنية تحتية لـ microfrontends تعد تكلفة هامشية وليست بندًا جديدًا في الميزانية. بالنسبة لهم، فإن استبدال اجتماعات المواءمة برسوم بيانية للنشر هو حساب منطقي.

السؤال الحقيقي هو أي فاتورة تتناسب بشكل أفضل مع فريقك. تفرض عليك الـ Monoliths ضريبة عند حدود التنسيق البشري، بينما تفرض عليك الـ Microfrontends ضريبة عند أساس هندسة المنصات.

اختيار عملتك

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

  • غلاف تشغيل (runtime shell) يتولى عمليات التكوين، والتوجيه، وحدود الخطأ بين الأجزاء.
  • سياسة تبعيات مشتركة تركز على استراتيجية إزالة التكرار، وليس على منطق التنفيذ المشترك.
  • اختبار عقود عابر للفرق لكل سطح تكامل.
  • قدرة موحدة على المراقبة (observability) يمكنها ربط نقرة المستخدم عبر الحزم الموزعة.
  • نموذج حوكمة للأداء، لأنه لا يوجد فريق واحد يمتلك الحمولة النهائية التي يقوم المتصفح بتنزيلها.

إذا اخترت الـ monolith، فكن صادقًا بشأن الفاتورة. أنت تشتري البساطة مقابل المزامنة. توقع الدفع مقابل:

  • ملكية مشتركة للكود وطقوس الحوكمة المطلوبة للحفاظ على تماسكها.
  • وتيرة إصدار يحددها أبطأ اختبار تكامل في أنابيب النشر.
  • نطاق تأثير واسع (blast radius) عند ترقية المكتبات.
  • الواقع الزاحف بأن أسرع مهندسيكم سيتحركون بسرعة أكثرهم حذرًا.

الخلاصة الحقيقية

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