На что похожа гексагональная архитектура в классических архитектурах?

Гексагональная архитектура в контексте классических архитектурных паттернов

Гексагональную архитектуру (также известную как Ports and Adapters) можно сравнить с многослойной (n-layered) архитектурой, но с кардинально иным подходом к направлению зависимостей и изоляции ядра системы.

Ключевое сходство: разделение ответственности

Как и в классической многоуровневой архитектуре (Presentation Layer, Business Logic Layer, Data Access Layer), гексагональная архитектура строго разделяет ответственность. Однако если в классическом подходе слои представляют собой "пирог" с жёсткой иерархией и зависимостями сверху вниз, то в гексагональной архитектуре ядро приложения (домен) находится в центре, а все остальные компоненты "вращаются" вокруг него, адаптируя внешний мир к его потребностям.

// Пример структуры в гексагональной архитектуре (ядро не зависит от внешнего мира)
// domain/core/ - ЯДРО (сущности, бизнес-правила, порты)
// adapters/input/ - Адаптеры входящие (REST контроллеры, CLI команды)
// adapters/output/ - Адаптеры исходящие (репозитории к БД, вызовы внешних API)
// infrastructure/ - Реализации адаптеров (технические детали)

Аналогия с архитектурой "Очищенное ядро" (Onion Architecture)

Наиболее близкая классическая аналогия — Onion Architecture, предложенная Джеффри Палермо. В обеих архитектурах:

• Доменный слой (бизнес-логика) находится в центре и не зависит ни от чего внешнего.
• Зависимости направлены внутрь, к центру.
• Внешние concerns (база данных, UI, фреймворки) являются "внешними слоями", которые можно заменять.

Различие в том, что "луковица" подразумевает концентрические слои, а "гексагон" визуализирует порты (интерфейсы) как стороны шестиугольника, к которым подключаются адаптеры. Это делает акцент на идее, что система может иметь множество различных способов взаимодействия (не только UI и БД).

Сравнение с Многослойной архитектурой: инверсия зависимостей

В классической трёхслойной архитектуре слой бизнес-логики часто зависит от слоя данных (например, использует конкретные классы репозиториев). Это создаёт сильную связь и затрудняет тестирование.

Гексагональная архитектура инвертирует эту зависимость через Dependency Inversion Principle (DIP) из SOLID:

• Ядро определяет интерфейсы (порты) того, что ему нужно (например, UserRepository).
• Внешний слой (адаптер) предоставляет конкретную реализацию этих интерфейсов (например, MongoDbUserRepository).

// ПОРТ в ядре (не зависит от инфраструктуры)
public interface UserRepository {
    User findById(UserId id);
}

// АДАПТЕР во внешнем слое (зависит от порта ядра и от конкретной технологии)
public class PostgresUserRepository implements UserRepository {
    private final JdbcTemplate jdbcTemplate;

    @Override
    public User findById(UserId id) {
        // Реализация с использованием PostgreSQL
    }
}

Таким образом, ядро остаётся "незапятнанным" знаниями о базах данных, фреймворках или протоколах.

Сходство и отличие от SOA и Микросервисов

Гексагональная архитектура на уровне одного приложения (модуля) решает те же задачи, что сервис-ориентированная архитектура (SOA) на уровне системы сервисов:

• Чёткие контракты (интерфейсы).
• Слабая связанность компонентов.
• Возможность замены реализации.

Однако гексагональная архитектура не предписывает физическое разделение на разные процессы (как микросервисы), а фокусируется на логическом разделении и чистоте ядра внутри одной codebase. Она прекрасно может использоваться внутри каждого отдельного микросервиса, делая его внутреннюю структуру более гибкой и тестируемой.

Заключение

Гексагональную архитектуру можно считать эволюцией и логическим развитием идей многослойной архитектуры и DIP. Она берёт принцип разделения слоёв, но переворачивает его с ног на голову, ставя бизнес-домен в абсолютный приоритет и изолируя его от изменчивости внешнего мира. Это делает систему:

• Устойчивой к изменениям технологического стека.
• Легко тестируемой (ядро можно тестировать без базы данных, веб-сервера).
• Понятной, так как бизнес-правила не размазаны по коду, а сконцентрированы в одном месте.

Поэтому, отвечая кратко: гексагональная архитектура наиболее похожа на многослойную архитектуру, переосмысленную через призму Dependency Inversion Principle и сфокусированную на защите доменного ядра. Это не революционно новая идея, но очень последовательная и мощная комбинация проверенных временем принципов, оформленная в наглядную и практичную модель.