لماذا نبني أنظمة ERP كبنى متجانسة معيارية أولا

الانقسام يحدث عادة مبكرا جدا، ولسبب خاطئ

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

نبني أنظمة ERP أولا كبنى متجانسة معيارية (modular monolith). لم نندم على هذا القرار في أي مشروع. الهدف ليس تجنب التعقيد، بل مطابقة البنية المعمارية لما يحتاج فعليا إلى التغيير معا وما يحتاج فعليا إلى البقاء متسقا.

أين تقع حدود الوحدة

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

• يمتلك المخزون مستويات الأصناف والحجوزات والحركات.
• تمتلك المبيعات الطلبات والتسعير وحالة التنفيذ.
• تمتلك الفوترة مستندات الفوترة وحالة الدفع.
• تمتلك سجلات العملاء بيانات التواصل وشروط الدفع وتاريخ المراسلات.

تفرض مراجعة الشيفرة قاعدة واحدة: يمكن لوحدة أن تستدعي واجهة خدمة وحدة أخرى، لكن لا يمكنها الاستعلام عن جداولها. هذه القاعدة الواحدة هي ما يجعل الاستخراج لاحقا ممكنا، لأن الحدود مصممة منذ اليوم الأول على شكل استدعاء شبكي، حتى قبل وجود أي استدعاء شبكي فعلي.

ما يجب أن يبقى في معاملة واحدة

العمليات التي يجب أن تكون ذرية في نظام ERP هي بالضبط تلك التي يصعب جعلها ذرية عبر خدمات منفصلة: حجز المخزون وتأكيد الطلب، ترحيل فاتورة وتحديث حالة الطلب، تطبيق دفعة وإلغاء تجميد ائتماني. في بنية متجانسة معيارية، تُنفَّذ هذه العمليات داخل معاملة قاعدة بيانات واحدة بضمانات ACID المعتادة. أما في نظام مقسّم مبكرا، تحتاج العملية نفسها إلى معاملات تعويضية متعاقبة ونافذة زمنية يظل فيها النظام غير متسق. تخرج معظم تذاكر الدعم من هذه النافذة بالذات.

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

متى ننقسم فعلا

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

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

توصيتنا

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