قم بتنفيذ طبقة واجهة أو محول بين أنظمة فرعية مختلفة لا تشترك في نفس الدلالات. تقوم هذه الطبقة بترجمة الطلبات التي يقدمها أحد الأنظمة الفرعية إلى النظام الفرعي الآخر. استخدم هذا النمط للتأكد من أن تصميم التطبيق لا يقتصر على التبعيات على الأنظمة الفرعية الخارجية. تم وصف هذا النمط لأول مرة بواسطة إريك إيفانز في التصميم المستند إلى المجال.
السياق والمشكلة
تعتمد معظم التطبيقات على أنظمة أخرى للحصول على بعض البيانات أو الوظائف. على سبيل المثال، عند ترحيل تطبيق قديم إلى نظام حديث، فقد يظل بحاجة إلى موارد قديمة موجودة. يجب أن تكون الميزات الجديدة قادرة على استدعاء النظام القديم. هذا ينطبق بشكل خاص على عمليات الترحيل التدريجي، حيث يتم نقل ميزات مختلفة لتطبيق أكبر إلى نظام حديث بمرور الوقت.
غالباً ما تعاني هذه الأنظمة القديمة من مشكلات الجودة مثل مخططات البيانات المعقدة أو واجهات برمجة التطبيقات القديمة. يمكن أن تختلف الميزات والتقنيات المستخدمة في الأنظمة القديمة بشكل كبير عن الأنظمة الأكثر حداثة. للتفاعل مع النظام القديم، قد يحتاج التطبيق الجديد إلى دعم البنية الأساسية القديمة أو البروتوكولات أو نماذج البيانات أو واجهات برمجة التطبيقات أو غيرها من الميزات التي لم تكن لتضعها في تطبيق حديث.
يمكن أن يؤدي الحفاظ على الوصول بين الأنظمة الجديدة والقديمة إلى إجبار النظام الجديد على الالتزام على الأقل ببعض واجهات برمجة التطبيقات الخاصة بالنظام القديم أو دلالات أخرى. عندما تحتوي هذه الميزات القديمة على مشكلات تتعلق بالجودة، فإن دعمها "يتلف" ما يمكن أن يكون تطبيقاً حديثاً مصمماً بطريقة نظيفة.
يمكن أن تنشأ مشكلات مماثلة مع أي نظام خارجي لا يتحكم فيه فريق التطوير لديك، وليس فقط الأنظمة القديمة.
حل
اعزل الأنظمة الفرعية المختلفة عن طريق وضع الطبقة المضادة للتلف بينها. تقوم هذه الطبقة بترجمة الاتصالات بين النظامين، ما يسمح لنظام واحد بالبقاء دون تغيير بينما يمكن للآخر تجنب المساس بتصميمه ونهجه التكنولوجي.
يوضح الرسم البياني أعلاه تطبيقاً بنظامين فرعيين. يستدعي النظام الفرعي A النظام الفرعي B من خلال الطبقة المضادة للتلف. يستخدم الاتصال بين النظام الفرعي A والطبقة المضادة للتلف دائماً نموذج البيانات وبنية النظام الفرعي A. تتوافق المكالمات من الطبقة المضادة للتلف إلى النظام الفرعي B مع نموذج أو طرق بيانات هذا النظام الفرعي. تحتوي الطبقة المضادة للتلف على كل المنطق الضروري للترجمة بين النظامين. يمكن تنفيذ الطبقة كمكون داخل التطبيق أو كخدمة مستقلة.
المسائل والاعتبارات
- قد تضيف الطبقة المضادة للتلف زمن انتقال للمكالمات التي يتم إجراؤها بين النظامين.
- تضيف الطبقة المضادة للتلف خدمة إضافية يجب إدارتها وصيانتها.
- ضع في اعتبارك كيف سيتم توسيع نطاق الطبقة المضادة للتلف.
- ضع في اعتبارك ما إذا كنت بحاجة إلى أكثر من طبقة واحدة من الطبقات المضادة للتلف. قد ترغب في تحليل الوظائف إلى خدمات متعددة باستخدام تقنيات أو لغات مختلفة، أو قد تكون هناك أسباب أخرى لتقسيم الطبقة المضادة للتلف.
- ضع في اعتبارك كيفية إدارة الطبقة المضادة للتلف فيما يتعلق بتطبيقاتك أو خدماتك الأخرى. كيف سيتم دمجها في عمليات المراقبة والإصدار والتكوين؟
- تأكد من الحفاظ على اتساق العمليات والبيانات ويمكن مراقبتها.
- ضع في اعتبارك ما إذا كانت الطبقة المضادة للتلف تحتاج إلى التعامل مع جميع الاتصالات بين الأنظمة الفرعية المختلفة، أو مجرد مجموعة فرعية من الميزات.
- إذا كانت الطبقة المضادة للتلف جزءاً من إستراتيجية ترحيل التطبيق، ففكر فيما إذا كانت ستكون دائمة، أو سيتم إيقافها بعد ترحيل جميع الوظائف القديمة.
- يتم توضيح هذا النمط مع الأنظمة الفرعية المميزة أعلاه، ولكن يمكن تطبيقه على بنيات الخدمة الأخرى أيضا، مثل عند دمج التعليمات البرمجية القديمة معا في بنية متجانسة.
موعد استخدام النمط
استخدم هذا النمط عندما:
- من المخطط أن يحدث الترحيل على مراحل متعددة، ولكن التكامل بين الأنظمة الجديدة والقديمة يحتاج إلى الحفاظ عليه.
- نظامان فرعيان أو أكثر لهما دلالات مختلفة، لكنهما لا يزالان بحاجة إلى التواصل.
قد لا يكون هذا النمط مناسباً إذا لم تكن هناك اختلافات دلالية بين الأنظمة الجديدة والقديمة.
تصميم حمل العمل
يجب على المهندس المعماري تقييم كيفية استخدام نمط طبقة مكافحة الفساد في تصميم حمل العمل الخاص بهم لمعالجة الأهداف والمبادئ التي تغطيها ركائز Azure Well-Architected Framework. على سبيل المثال:
| الركيزة | كيف يدعم هذا النمط أهداف الركيزة |
|---|---|
| يساعد التميز التشغيلي على تقديم جودة حمل العمل من خلال العمليات الموحدة وتماسك الفريق. | يساعد هذا النمط على ضمان بقاء تصميم المكونات الجديدة غير متأثر بالتكوينات القديمة التي قد يكون لها نماذج بيانات أو قواعد عمل مختلفة عند التكامل مع هذه الأنظمة القديمة ويمكن أن يقلل من الديون التقنية في المكونات الجديدة مع الاستمرار في دعم المكونات الحالية. - OE:04 الأدوات والعمليات |
كما هو الحال مع أي قرار تصميم، ضع في اعتبارك أي مفاضلات ضد أهداف الركائز الأخرى التي يمكن إدخالها مع هذا النمط.