بنية مناسبة لإعادة كتابة مع سيناريو التكامل + الترحيل

Question

لقد بدأنا مؤخرًا مشروعًا في الشركة التي أعمل عليها لإعادة هيكلة وإعادة كتابة مشهد أنظمةنا وإنقاذ مستقبل أطفالنا.

لدينا 3-4 أنظمة قديمة لا يمكن تكييفها على الإطلاق مع حالات الاستخدام الجديدة بسبب الرمز المروع ، ولكن لا يزال يتعامل مع قدر كبير من الطلبات يوميًا عبر واجهات وتنسيقات مختلفة مثل البريد الإلكتروني و XMLRPC و WebInterface.

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

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

أجد نهج "خدمة البيانات الأساسية/المشتركة" مشكلة كبيرة إذا كان لدي كيانات لها الكثير من العلاقات مثل الترتيب ، مع رسم بياني كبير. إذا قمت بإنشاء خدمة فردية لعمليات CRUD بناءً على الطلبات والكيانات الأخرى لتأسيسها أكثر تجريدًا ، فسيكون من المستحيل حقًا التعامل مع الحمض أو النزاهة العلائقية أو يجب عليك التضحية باستقلالية تلك الخدمات والترابط هم ، مما يجعل الخدمات عديمة الفائدة جدا (وربما بطيئة جدا). أو هل فهمت شيئًا خاطئًا؟

لذلك كانت فكرتي هي ببساطة إنشاء DAL "تقليدي" باستخدام JPA Pojos لطيف ، بالطبع مع واجهات ، ونشرها كحزمة OSGI بسيطة ومصورة من أجل استخدام خدمات الأعمال والعمليات ، لها رسم خرائط أكثر تجريدية. هذه الخدمات ستستخدمها ببساطة وفضح واجهة الحافلة. لخدمة الحالة النادرة المتمثلة في الحاجة إلى الوصول إلى البيانات الفردية ، مثل إثراء المحتوى في استيراد أو الإبلاغ عن البيانات الجمل أو الإبلاغ ، يمكن إنشاء "خدمة جميع الكيانات" القبيحة والتي من شأنها حل مشكلة الحمض والنزاهة.

حتى الآن جيد جدًا ، ولكن: كيف ينبغي على Webui (الذي هو في الغالب Crud كما ذكرت ، وبالتالي ليس عملية مجردة بالفعل) الوصول إلى البيانات؟ من شأن استخدام JPA Pojos أن يجعله يقترن بشكل كبير ، ولكن إنشاء رسم خرائط وإدخال نموذج آخر متطابق تقريبًا واستخدام "Monster Dal Service" المذكور أعلاه لا يبدو جيدًا أيضًا.

ما رأيك؟ أين التوازن الجيد بين الشعور والأناقة والعملية؟

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

شكرا لوقتك :)

Answer 1

هذه ليست إجابة كبيرة مثل ملاحظة تتمنى لك حظًا جيدًا.

لدينا موقف هو نفس الشكل/مختلف لك ، وهو يثبت أنه من الصعب للغاية التعامل معه بفعالية.

أعتقد أن نهجك على ما يرام ، يبدو أنك تحضر توازنًا جيدًا.

يمكنك أخذ أنماط تكامل المؤسسات مثل تلك نشرته مارتن فاولر, ، ولكن ما إذا كان ذلك سيصل بك إلى المكان الذي تريده / تحتاج إلى أن تظل لابد من رؤيته.

خيارات أخرى: هناك آلة "النقانق": حيث تدفع النظام القديم إلى نظام ينشئ رمز "جديد" (في Java أو .NET) الذي يصبح نظامك الجديد. والشيء الجيد هو أن لديك الآن قاعدة كود بلغة يمكنك العمل معها ، والخبر السيئ هو أنها ستكون أكبر كومة من Spagetti الأكثر روعة التي تخيلتها على الإطلاق.

حتى ذلك الحين إنها مهمة ضخمة. أمضت وكالة حكومية هنا سنتين أو 3 سنوات و 5 ملايين دولار في الحصول على هذا. لم تكن جميلة أو غير مؤلمة ولكن يبدو أنها نجحت. إذا سألت حول ما يكفي (أي: ليس على Stackoverflow) ، فيجب أن تجد أشخاصًا تعاملوا مع ترحيل المنصات التي تمسك بها ، ودخل في محادثة معهم.