لماذا نبدأ بالكتلة المعيارية (Modular Monolith)

الخلاصة

نبدأ أنظمة الأعمال الجديدة ككتلة معيارية: تطبيق واحد قابل للنشر، مقسَّم من الداخل إلى وحدات بحدود واضحة. ولا تنتقل وحدة إلى خدمة مستقلة إلا عندما يستدعي ذلك متطلب محدد.

ما الذي يسوء عندما تسبق الخدمات الفهم

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

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

ما تحتفظ به الكتلة المعيارية

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

كيف نُبقي الحدود حقيقية

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

متى نفصل خدمة فعلاً

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

في منتجاتنا

منصة RumuzePMO كتلة معيارية بـ Laravel من سبع وحدات يمكن تفعيلها بشكل مستقل. وتعمل على FrankenPHP وOctane مع طوابير مدعومة بـ Redis، وتتكامل مع عدة بوابات دفع.