Cloud Design Patterns - Anti corruption Layer

یک لایه façade یا adapter بین زیرسیستم های مختلف که معنایی یکسانی ندارند پیاده سازی کنید. این لایه درخواست هایی را که یک زیر سیستم می کند به زیرسیستم دیگر ترجمه می کند. از این الگو استفاده کنید تا اطمینان حاصل کنید که طراحی یک برنامه توسط وابستگی به زیرسیستم های خارجی محدود نمی شود. این الگو اولین بار توسط Eric Evans در طراحی دامنه محور توصیف شد.

طرح صورت مسئله:

اکثر برنامه ها برای برخی داده ها یا عملکردها به سیستم های دیگر متکی هستند. به عنوان مثال، هنگامی که یک برنامه قدیمی به یک سیستم مدرن منتقل می شود، ممکن است همچنان به منابع قدیمی موجود نیاز داشته باشد. ویژگی های جدید باید قادر به فراخوانی سیستم قدیمی باشند. این به ویژه در مورد مهاجرت های تدریجی صادق است، جایی که ویژگی های مختلف یک برنامه بزرگتر به مرور زمان به یک سیستم مدرن منتقل می شود.

اغلب این سیستم های قدیمی از مشکلات کیفی مانند طراحی داده های پیچیده و در هم تنیده یا API های منسوخ رنج می برند. ویژگی‌ها و فناوری‌های مورد استفاده در سیستم‌های قدیمی می‌تواند به طور گسترده‌ای با سیستم‌های مدرن‌تر متفاوت باشد. برای تعامل با سیستم قدیمی، برنامه جدید ممکن است نیاز به پشتیبانی از زیرساخت‌های قدیمی، پروتکل‌ها، مدل‌های داده، APIها یا سایر ویژگی‌هایی داشته باشد.

حفظ دسترسی بین سیستم‌های جدید و قدیمی می‌تواند سیستم جدید را مجبور کند حداقل به برخی از APIهای سیستم قدیمی یا دیگر معنایی‌ها پایبند باشد. وقتی این ویژگی‌های قدیمی مشکلات کیفی دارند، توسعه برنامه مدرن که وابستگی به برنامه قدیمی را دارد تحت تاثیر قرار میدهد و کیفیت نهایی بخاطر مشکل طرح قدیمی، مطلوب نیست.

مشکلات مشابهی ممکن است در مورد هر سیستم خارجی که تیم توسعه شما کنترل نمی کند، نه فقط سیستم های قدیمی، ایجاد شود.

راه حل:

زیرسیستم های مختلف را با قرار دادن یک لایه anti-corruption بین آنها جدا کنید. این لایه ارتباطات بین دو سیستم را ترجمه می کند و به یک سیستم اجازه می دهد بدون تغییر بماند در حالی که دیگری می تواند از به خطر افتادن طراحی و رویکرد تکنولوژیکی خود جلوگیری کند.

نمودار بالا یک برنامه کاربردی با دو زیرسیستم را نشان می دهد. زیرسیستم A از طریق یک لایهanti-corruption به زیر سیستم B فراخوانی می کند. ارتباط بین زیرسیستم A و لایه anti-corruption همیشه از مدل داده و معماری زیرسیستم A استفاده می کند. تماس ها از لایه anti-corruption به زیر سیستم B مطابق با مدل یا روش های داده آن زیر سیستم است. لایه anti-corruption حاوی تمام منطق لازم برای ترجمه بین دو سیستم است. لایه را می توان به عنوان یک جزء در برنامه یا به عنوان یک سرویس مستقل پیاده سازی کرد.

مسائل و ملاحظات:

• لایه anti-corruption ممکن است به تماس های برقرار شده بین دو سیستم تاخیر بیافزاید.
• لایه anti-corruption یک سرویس اضافی اضافه می کند که باید مدیریت و نگهداری شود.
• در نظر بگیرید که لایه anti-corruption شما چگونه scale خواهد شد.
• در نظر بگیرید که آیا به بیش از یک لایه anti-corruption نیاز دارید یا خیر. ممکن است بخواهید با استفاده از فناوری ها یا زبان های مختلف عملکرد را به چندین سرویس تجزیه کنید، یا ممکن است دلایل دیگری برای تقسیم لایه anti-corruption وجود داشته باشد.
• در نظر بگیرید که چگونه لایه anti-corruption در رابطه با سایر برنامه ها یا خدمات شما مدیریت می شود. چگونه در فرآیندهای نظارت، انتشار و پیکربندی شما یکپارچه خواهد شد؟
• اطمینان حاصل کنید که تراکنش ها و داده ها سازگاری دارند و قابل نظارت هستند.
• در نظر بگیرید که آیا لایه anti-corruption نیاز به مدیریت همه ارتباطات بین زیرسیستم های مختلف دارد یا فقط زیر مجموعه ای از ویژگی ها.
• اگر لایه anti-corruption بخشی از یک استراتژی ارتقا برنامه است، در نظر بگیرید که آیا دائمی خواهد بود یا پس از انتقال همه عملکردهای قدیمی بازنشسته می شود.

چه زمانی از این الگو استفاده کنیم؟

از این الگو زمانی استفاده کنید که:

• اینکه پروسه migrate و ارتقا دادن برنامهاز حالت قدیم به جدید یک پروسه چند مرحله‌ای برنامه ریزی شده است، با توجه به اینکه یکپارچگی بین سیستم های جدید و قدیمی باید حفظ شود.
• دو یا چند زیرسیستم semantic متفاوتی دارند، اما همچنان نیاز به ارتباط دارند.

اگر تفاوت semantic قابل توجهی بین سیستم های جدید و قدیمی وجود نداشته باشد، ممکن است این الگو مناسب نباشد.