اتصل بنا للحصول على عرض أسعار مخصص من FinMV يناسب احتياجاتك.
سيتعين على المدير الفني لشركتك ، عند التخطيط لإطلاق منصة مالية ، اختيار خيار هندسة المشروع. ما هي خيارات الهندسة المعمارية المتاحة له وأيها أفضل للاختيار؟
الهندسة المعمارية المتجانسة تشبه كرة الثلج . تبدأ مشروعًا ولديك كرة ثلجية صغيرة. إنه صغير جدًا بحيث يمكن تطويره وتدويره بواسطة فريق صغير. مر عامان ، والآن أصبحت كرة الثلج الخاصة بك ضخمة جدًا لدرجة أن 20 من مطوري البرامج يدفعون بها بالفعل. في غضون عامين آخرين ، سوف يقوم مئات من مطوري البرامج بإدخال الكثير من التعليمات البرمجية ، لكن إطلاق الميزات الجديدة سيصبح بطيئًا للغاية.
نتيجة لذلك ، يبدأ المالكون في تغيير المدير الفني وأعضاء الفريق ، ولكن الأمر يزداد سوءًا . أعضاء الفريق الجدد لا يعرفون التفاصيل التاريخية ، لماذا كرة الثلج على ما هي عليه وليس غيرها. وثائق المنتج تصبح قديمة بسرعة.
لماذا لا تفعل ذلك بالشكل الصحيح منذ البداية؟ أولاً ، في بداية النشاط التجاري ، هناك دائمًا الموارد محدودة ، ولا يوجد عدد كافٍ من المطورين والخبرة والوقت. يحث الدليل ، والمبرمجون في عجلة من أمرهم للقيام بذلك بأسرع طريقة ممكنة.
ثانيًا ، يعتقد المهندسون الفنيون: "حسنًا ، فليكن هيكلًا مترابطًا في الوقت الحالي ، ولكن عندما ينمو النشاط التجاري ، سنعيد كل شيء" . لسوء الحظ ، في الواقع ، سيكون نقل مشروع مترابط حالي إلى بنية خدمات مصغرة أكثر صعوبة بمقدار عشرات مرات من كتابة كل شيء من البداية.
سنجعل النظام الأساسي المالي الخاص بك على الفور قائمًا على بنية الخدمات المصغرة.
يمكن مقارنة بنية الخدمات المصغرة بألواح الرصف على ممرات المشاة. مع نمو مشروعك ، تتم إضافة المزيد من البلاط إلى الممشى الخاص بك. إذا كان أحد المكونات قديمًا ، فيكفي استبدال هذا المربع بأخرى جديدة.
تتمتع هذه البنية بالعديد من المزايا ، لكنني سأذكر أهمها:
المثال الأول. قررت إدارة منصة إقراض P2P مع عدد كبير من المستخدمين دخول أسواق البلدان بعملة مختلفة. كان للمنصة بنية متجانسة وتضمنت عملة واحدة فقط - اليورو ، وللدخول إلى أسواق السويد (كرونة سويدية) وبولندا (الزلوتي البولندي) وجمهورية التشيك (التاج التشيكي) كان من الضروري إدخال عملات متعددة.
لقد استغرق الفريق بأكمله شهورًا لتنفيذ هذه الوظيفة ، وتباطأ تطوير وظائف جديدة أكثر. في حالة بنية الخدمات المصغرة ، سيكون كل شيء أسهل وأسرع بكثير.
المثال الثاني. في البداية ، تم إطلاق أداة إنشاء المواقع باللغة الأم ولم تكن الإدارة تتوسع في أسواق أخرى. كان للمشروع بنية متجانسة ، ونمت الوظيفة بسرعة. كان مخطط النظام الأساسي عبارة عن شبكة ويب معقدة حيث كان كل شيء متصلاً بكل شيء. ذات يوم ، قررت الشركة إصدار نسخة من النظام الأساسي بلغات أخرى. في البداية ، بدا أنه يكفي إضافة ملفات اللغة فقط والآن سنترجم الواجهة بالكامل.
من الناحية العملية ، كان لا بد من إعادة تصميم المشروع بأكمله. على سبيل المثال ، يجب الآن تخزين أسماء الشركات والمنتجات في قاعدة البيانات ليس فقط بلغة واحدة ، ولكن بكل لغة. كان من المستحيل تكرار المعلومات بسبب منطق الأعمال ، كان من الضروري تخزين الأسماء لجميع اللغات في وقت واحد. وفقًا لذلك ، أدى ذلك إلى تغييرات في واجهات مجلس الوزراء والمكتب الخلفي. تتطلب تغييرات الواجهة تغيير قواعد التحقق من صحة البيانات الواردة ، وقوالب الرسائل بسبب مبادئ مختلفة للنهايات بلغات مختلفة ، وتغيير الاختبارات ، وما إلى ذلك.
نظرًا لأن كل شيء كان متصلاً بكل شيء ، فقد تم اتخاذ القرار بالانتقال إلى بنية الخدمات المصغرة جنبًا إلى جنب مع إطلاق لغات جديدة. استغرقت عملية الانتقال من البنية المتجانسة إلى بنية الخدمات المصغرة أكثر من عام.
المثال الثالث. تم إنشاء النظام الأساسي للتكنولوجيا المالية على إصدار قديم من PHP و Laravel. كانت الترقية إلى إصدارات أحدث ، وكذلك تغيير قاعدة البيانات من MariaDB إلى PostgreSQL ، أمرًا مستحيلًا تقريبًا ، حيث كان على الفريق بأكمله التعامل مع عملية الترحيل فقط لعدة أشهر.
يمكن للإصدارات الجديدة من PHP و Laravel في ذلك الوقت تسريع المشروع والمزيد من التطوير ، لكن البنية المتجانسة لم تسمح بتحديث مكدس التكنولوجيا
.
