Adapter — согласование несовместимых интерфейсов между компонентами

Adapter позволяет двум несовместимым интерфейсам работать вместе, преобразуя запросы одного формата в другой. Паттерн устраняет жёсткие связи при интеграциях и позволяет повторно использовать существующие компоненты, библиотеки и сервисы.

Adapter особенно полезен при подключении внешних систем, миграции наследия, интеграции старого API с новым, адаптации протоколов или при стандартизации интерфейсов.

Устраняя несовместимость интерфейсов, Adapter снижает стоимость интеграций и повышает гибкость архитектуры.

Adapter является одним из ключевых инструментов архитектора, потому что в реальных информационных системах компоненты, сервисы, библиотеки и протоколы редко совпадают друг с другом по структуре. Системы развиваются, меняют API, переходят на новые версии, интегрируются со сторонними платформами, и почти всегда появляется необходимость привести разные интерфейсы к единообразному виду — без переписывания существующего кода.

Главная идея Adapter

Adapter превращает интерфейс А в интерфейс В, чтобы:

• клиент продолжал работать со своим привычным контрактом;

• а адаптер обеспечивал преобразование в реальный формат.

Это позволяет интегрировать «чужие» классы или сервисы без нарушения архитектуры.

Где Adapter применяется в архитектуре ИС

1. Интеграция с внешними системами

Один сервис говорит:

getUser(id)

Другой — требует:

fetchClientByKey(key)

Adapter решает разницу без изменения сторон.

Используется в интеграциях:

• банковских API,

• госуслуг,

• телеком-платформ,

• ERP/CRM,

• платёжных шлюзов,

• внутренних старых систем.

2. Миграции и модернизация Legacy

При переходе на новую платформу нельзя переписать сразу всё.

Старая система имеет один интерфейс, новая — другой.
Adapter позволяет подключать новые модули к старым без рефакторинга всей системы.

3. Переход между разными типами API

• REST → gRPC

• SOAP → REST

• файловые интерфейсы → сервисные интерфейсы

• старые DTO → новые DTO

• XML → JSON

• разные схемы авторизации

В каждом случае Adapter оформляет преобразование и стандартизацию.

4. Упрощение бизнес-логики (чистая архитектура)

В чистой архитектуре:

• бизнес-логика не должна знать об инфраструктуре;

• инфраструктура подключается через адаптеры.

Например:

• адаптер БД,

• адаптер очереди,

• адаптер API,

• адаптер файловой системы.

Это обеспечивает независимость домена от технологий.

5. Интеграция сторонних библиотек

Библиотеки часто имеют неудобные или нестабильные интерфейсы.
Архитектор использует Adapter для:

• стандартизации вызовов,

• снижения риска привязки к конкретной библиотеке,

• упрощения тестирования.

Типы Adapter

1. Object Adapter (через композицию)

Наиболее гибкий вариант — адаптер «оборачивает» нужный объект.

2. Class Adapter (через наследование)

Реже используется, так как требует множественного наследования.

Преимущества Adapter

• Изоляция изменений внешнего интерфейса
  Меняется внешний API → меняем только адаптер.

• Уменьшение связанности
  Компоненты взаимодействуют через единый стандарт.

• Повторное использование
  Можно подключать старые компоненты к новым системам.

• Легкость тестирования
  Адаптеры можно мокировать.

Недостатки

• может появиться слишком много адаптеров → нужен каталог;

• риск «зарыть» архитектурные проблемы под адаптерами;

• иногда лучше изменить интерфейс, а не адаптировать устаревший контракт.

Adapter в учебниках по архитектуре ИС

В загруженных учебниках (Орлова, Беляев, Трутнев, Кукоцев, Сухомлинов, Замотайлова) паттерн Adapter упоминается:

• как основа интеграции подсистем;

• как ключевой механизм унификации интерфейсов;

• как часть уровня взаимодействия в корпоративных ИС;

• как базовый инструмент при миграции Legacy;

• как элемент архитектурного слоя адаптации.

Почему архитектор обязан владеть Adapter

Потому что 90% реальной архитектурной работы — это интеграции.
И почти всегда форматы данных, API и протоколы несовместимы.

Архитектор, владеющий Adapter:

• изолирует бизнес от технического хаоса;

• делает систему расширяемой;

• минимизирует изменения при миграции API;

• обеспечивает устойчивость интеграций;

• снижает стоимость поддержки.