تطبيق موحّد أم خدمات مصغرة؟ ابدأ بحدود العمل

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

ارسم حدود المجال قبل الخوادم

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

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

اجعل التطبيق الموحّد منظمًا بالفعل

في modular monolith تُنشر الأجزاء كتطبيق واحد، مع وحدات داخلية ذات مسؤوليات وواجهات واضحة. يناقش Martin Fowler فائدة البدء بتطبيق موحّد عندما تكون الحدود غير مستقرة، مع التنبيه إلى أن التفكيك اللاحق ليس مضمون السهولة.

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

احسب مسؤولية تشغيل الخدمات

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

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

اختبر سببًا محددًا للفصل

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

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

وثّق القرار وإشارة مراجعته

اختم بورقة قرار قصيرة تسجل الاختيار، والافتراضات، والمسؤوليات، والبدائل المستبعدة وأسبابها. حدد ظروف المراجعة، مثل تعارض مواعيد النشر بين فرق مستقلة أو ظهور احتياج واضح لعزل حمل معين.

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

خطوتك التالية

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