الواجهات المصغّرة في الواقع: دروس من منصة حكومية مؤسسية

لماذا الواجهات المصغّرة؟

عندما تنمو المنصة لتتجاوز فريقًا واحدًا، يصبح تطبيق Next.js الواحد عنق زجاجة. تتيح الواجهات المصغّرة للفرق النشر باستقلالية — لكن لها تكاليف حقيقية.

ما نجح معنا

1. نظام تصميم مشترك أولًا. قبل تقسيم التطبيقات، بنينا مكوّنات قابلة لإعادة الاستخدام بـ Tailwind CSS وStorybook، فأصبح الاتساق بين الوحدات أمرًا مضمونًا.
2. حدود واضحة للوحدات. كل واجهة مصغّرة تملك نطاق أعمال كاملًا وليس صفحة واحدة، والميزات المشتركة تمر عبر عقود صريحة.
3. Monorepo. أدوات مشتركة، وخط CI واحد، وتغييرات ذرّية عبر الوحدات.

ما يجب الحذر منه

• انحراف الاعتماديات — ثبّت إصدارات الاعتماديات المشتركة، وإلا ستجد وحدتين بإصدارين مختلفين من React.
• نقاط التنقل — يجب أن يبدو التنقل بين الوحدات طبيعيًا؛ استثمر مبكرًا في موجّه رئيسي (Shell Router).
• الإفراط في التقسيم — إذا كانت وحدتان تتغيران دائمًا معًا، فهما وحدة واحدة.

الخلاصة

الواجهات المصغّرة أداة تنظيمية وليست أداة أداء. اعتمدها عندما يؤلمك توسّع الفرق، لا لأنها رائجة.