هندسة الخدمات المصغّرة: متى تستخدمها ومتى تتجنبها

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

متى تكون الخدمات المصغرة منطقية

1. المجالات الكبيرة المعقّدة

إذا كان تطبيقك يمتد عبر سياقات محدودة متعددة بفِرَق متمايزة، تتيح الخدمات المصغرة التطوير والنشر المستقلَّين:

• منصّات التجارة الإلكترونية (الطلبات، المخزون، المدفوعات، الشحن)
• تطبيقات المؤسسات بوحدات أعمال متمايزة
• المنصّات التي تتطلّب خصائص توسّع مختلفة لكل خدمة

2. متطلّبات التوسّع

عندما تكون لأجزاء مختلفة من تطبيقك احتياجات توسّع متباينة جداً:

// Image processing service: needs GPU, scales based on queue depth
// User API: CPU-bound, scales based on request rate
// Notification service: I/O-bound, scales based on event volume

3. تنوّع التقنيات

عندما تتطلّب المشكلات المختلفة حلولاً مختلفة:

• خدمات تعلّم الآلة بلغة Python
• الميزات الفورية بلغة Go أو Rust
• عمليات CRUD بلغة Node.js أو Ruby

متى تلتزم بالأحادي (Monolith)

1. الفِرَق الصغيرة

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

2. الشركات الناشئة في مراحلها المبكرة

عندما لا تزال تكتشف مجالك وتُغيّر مساره بشكل متكرّر، يتيح الأحادي تكراراً أسرع:

"ابدأ بأحادي، واستخرج الخدمات المصغرة عند الحاجة" — Martin Fowler

3. المجالات البسيطة

ليس كل تطبيق يحتاج إلى معالجة ملايين الطلبات. فمدوّنة أو أداة داخلية أو SaaS بسيط يمكن أن تعمل بشكل ممتاز كأحادي.

دراسة حالة: عندما أخطأنا

شركة ناشئة في التكنولوجيا المالية استشرتُها بدأت بـ 15 خدمة مصغرة لفريق من 5 مطوّرين. النتيجة:

• 50% من الوقت أُنفق على البنية التحتية بدلاً من الميزات
• تصحيح المعاملات الموزّعة كان كابوساً
• الميزات البسيطة تطلّبت تغييرات عبر خدمات متعددة

الحل: دمجنا كل شيء في 3 خدمات بحدود واضحة، مقلّلين التعقيد مع الحفاظ على فوائد النشر المستقل لأكثر المسارات حرجاً.

الحل الوسط: الأحادي المعياري (Modular Monolith)

يمنحك الأحادي المعياري أفضل ما في العالمَين:

src/
├── modules/
│   ├── users/
│   │   ├── domain/
│   │   ├── application/
│   │   ├── infrastructure/
│   │   └── api/
│   ├── orders/
│   │   └── ...
│   └── payments/
│       └── ...
└── shared/
    ├── kernel/
    └── infrastructure/

المبادئ الأساسية:

1. حدود وحدات واضحة بواجهات مُعرّفة
2. لا وصول مباشر لقاعدة البيانات بين الوحدات
3. التواصل عبر الأحداث أو فئات الخدمات
4. سهولة الاستخراج إلى خدمات مصغرة لاحقاً عند الحاجة

اتخاذ القرار

اسأل نفسك هذه الأسئلة:

1. هل لدينا حدود مجال واضحة؟
2. هل نحتاج إلى توسّع أو نشر مستقل؟
3. هل لدينا حجم الفريق والخبرة؟
4. هل مجالنا مستقرّ بما يكفي؟

ينبغي أن تخدم المعمارية احتياجات عملك، لا العكس.