یک‌لایه نما(façade) یا آداپتور بین زیرسیستم‌های مختلف که معنایی یکسانی ندارند پیاده‌سازی کنید. این لایه requestهای یک زیرسیستم را برای زیرسیستم دیگر تفسیر و ترجمه می‌کند. از این الگو زمانی استفاده کنید تا اطمینان حاصل کنید که طراحی یک برنامه توسط وابستگی به زیرسیستم‌های خارجی محدود نمی‌شود. این الگو برای اولین‌بار توسط اریک ایوانز در Domain-Driven Design توصیف شد.
اکثر برنامه‌ها برای برخی داده‌ها یا عملکردها به دستگاه‌های دیگر متکی هستند. به‌عنوان‌مثال، هنگامی که یک برنامه قدیمی به یک سیستم مدرن منتقل می‌شود، ممکن است همچنان به منابع قدیمی موجود نیاز داشته باشد. ویژگی‌های جدید باید قادر به فراخوانی سیستم قدیمی باشند. این به‌ویژه در مورد migrationهای تدریجی صادق است، جایی که ویژگی‌های مختلف یک برنامه بزرگ‌تر به‌مرورزمان به یک سیستم مدرن منتقل می‌شود.
اغلب این سیستم های قدیمی از مشکلات کیفی مانند طراحی‌های داده‌های (data schemas) پیچیده یا 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 دررابطه‌با سایر برنامه‌ها یا سرویس‌های شما مدیریت می‌شود و چگونه در سیستم نظارت یا monitoring شما ادغام خواهد شد،
- اطمینان حاصل کنید که تراکنش‌ها و داده‌ها یکپارچگی دارند و قابل نظارت هستند.
- در نظر بگیرید که آیا لایه anti-corruption نیاز به مدیریت همه ارتباطات بین زیرسیستم‌های مختلف دارد یا فقط زیرمجموعه‌ای از ویژگی‌ها موردنیاز است.
- اگر لایه anti-corruption بخشی از یک راهبُرد migration برنامه است، در نظر بگیرید که آیا دائمی خواهد بود یا پس از انتقال همه عملکردهای قدیمی تعدیل می‌شود.
- این الگو با زیرسیستم‌های مجزا در بالا نشان‌داده‌شده است، اما می‌تواند برای سایر معماری‌های سرویس نیز اعمال شود، مانند زمانی که کدهای قدیمی را با هم در یک معماری یکپارچه ادغام می‌کنیم.
از این الگو زمانی استفاده کنید که:
- در حالتی که برنامه‌ریزی‌شده است که یک migration در چند مرحله اتفاق بیفتد، اما یکپارچگی بین سیستم های جدید و قدیمی حتماً باید حفظ شود. - دو یا چند زیرسیستم semantic متفاوتی دارند، اما همچنان نیاز به ارتباط دارند.
اگر تفاوت مفهومی قابل‌توجهی بین سیستم های جدید و قدیمی وجود نداشته باشد، ممکن است این الگو مناسب نباشد.