ITRampage

Anti Corruption Layer – це дуже корисна практика у розробці програмного забезпечення, яка вирішує проблему проникнення непотрібних деталей і відтак сплутанності коду. Найчастіше Anti Corruption Layer використовується у випадках, коли ми маємо справу з елементами системи, над якими не маємо влади, тобто т.з. 3rd-parties.

Проблема

Ми розробляємо певний значущий для бізнесу код. Нехай це буде система управління зверненнями (т.з. help desk) і у цій системі ми використовуєму бібліотеку для завантаження зображень у AWS S3.

Якщо API AWS S3 зміниться, то зміниться і реалізація відповідної бібліотеки-клієнта для роботи з S3. Або, можливо, розробники бібліотеки винайдуть більш зручне API для свого творіння. Інший вірогідний сценарій розвитку подій – це перехід на більш дешевого Cloud Service Provider’а, або перехід на виділені сервери.

У будь якому із цих випадків ми будемо змушені оновлювати т.з. бізнес логіку, якщо не використовували Anti Corruption Layer, через що код реалізації деталей (завантаження зображень на CDN) проник до коду більш високого рівня. Іншими словами, якщо ми не використовували Anti Corruption Layer, то наш код не відповідає принципам єдиної відповідальності (єдиної причини для зміни) (Single Responsibility) та інверсії залежностей (Dependency Inversion Principle), відповідно S та D в акронімі SOLID.

Порушення принципу єдиної відповідальності полягає у тому, що бізнес код має змінюватися не через запит від бізнесу, а через зміну в реалізації якоїсь не суттевої для бізнесу деталі.

Порушення принципу інверсії залежностей полягає у тому, що зміна коду, що умовно знаходиться знизу, викликає необхідність змін коду, що знаходиться умовно вище, а згідно Dependency Inversion Principle ми маємо використовувати низхідний (Top-Down) підхід, а не висхідний (Bottom-Up).

Принцип роботи Anti Corruption Layer

Anti Corruption Layer можна уявити як буферну зону, або як архітектурний патерн AirLock. Проблема, яку вирішують за допомогою Anti Corruption Layer, схожа на наступний парадокс, з яким зіштовхуються дизайнери інтер’єрів публічних закладів та архітектори хмарочосів: двері мають бути відчинені, аби люди могли заходити та виходити, і зачинені, аби холодне повітря не продувало людей, або навіть не видувало їх, як це може статися з потужною вентиляцією у хмарочосах.

Для вирішення цього парадоксу створюється невеличка технічна кімната/буферна зона з двома дверми. Коли ми відкриваємо перші двері, то другі залишаються зачиненими і протягу немає, коли ми відчиняємо другі двері, то перші вже зачинилися і протягу знову таки немає.

У випадку з використанням 3rd-party рішень, проблема має наступний вигляд: “Як використовувати 3rd-party та не забруднити код вищого рівня, що його використовує?”. А парадоксально вона описується так: “Як використовувати 3rd party, не використовуючи 3rd-party?”. Вихід із цієї ситуації – використання 3rd-party через Anti Corruption Layer, тобто саме Anti Corruption Layer буде нашою буферною зоною або airlock’ом.

Зверніть увагу на окремі стрілочки “Uses” та “Depends” на діаграмі вище. Юніт (функція, пакет, клас, модуль, …), що реалізує Anti Corruption Layer для юніту, що реалізує модель предметної області (domain), має саме той мінімальний інтерфейс, який необхідний для предметної області.

Наприклад, якщо нам необхідно десь завантажити зображення зі створеного у HelpDesk системі запиту, то Anti Corruption Layer реалізує лише один метод/функцію – Upload(<image data>). Таким чином, як би не змінювалась реальзація завантаження зображень, предметна область буде незмінною, як і інтерфейс Anti Corruption Layer’а. Якщо відбудуться якісь зміни у 3rd-party бібліотеці, то зміниться лише реалізація Anti Corruption Layer, але не його інтерфейс, бо він залежить не від 3rd-party, а від користувача – коду предметної області.

Сподіваюсь, моя публікація допомогла вам краще зрозуміти, як працює Anti Corruption Layer та які переваги надає. Якщо виникли питання – пишіть їх у коментарях.

Також рекомендую ознайомитися із близькою за темою публікацією – Як потоваришувати Top-Down та Bottom-Up підходи?