Чем гексагональная архитектура отличается от луковичной и чистой (Clean) архитектуры?

Общее ядро идей

Гексагональная, луковичная и чистая архитектуры — это вариации одной концепции: отделить бизнес-логику от внешних инфраструктурных деталей (базы данных, UI, API). Все они опираются на принцип инверсии зависимостей: зависимости направлены внутрь, к домену, а не наружу.

Гексагональная архитектура (Ports & Adapters)

В центре — домен, вокруг него — порты (интерфейсы) и адаптеры (реализации). Порты определяют, как внешний мир взаимодействует с приложением (входные порты) и как приложение взаимодействует с внешним миром (выходные порты). Адаптеры — это конкретные реализации, например, REST-контроллер или репозиторий на SQL.

// Входной порт
interface UserService {
  getUser(id: string): User;
}

// Выходной порт
interface UserRepository {
  findById(id: string): User;
}

// Адаптер для базы данных
class SqlUserRepository implements UserRepository {
  findById(id: string) { /* SQL запрос */ }
}

Луковичная архитектура

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

Чистая архитектура (Clean Architecture)

Предложена Робертом Мартином. Использует концентрические круги: entities, use cases, adapters, frameworks. Правило зависимости: внутренние круги не знают о внешних. Это более формализованная версия, с четкими названиями слоев и правилами.

Ключевые различия

• Терминология: порты/адаптеры vs слои vs круги.
• Акцент: гексагональная — на взаимодействии с внешним миром, луковичная — на слоях, чистая — на правилах зависимости.
• Строгость: чистая архитектура более строгая в определении границ, но на практике все три взаимозаменяемы.

Вывод

Выбор между ними — вопрос вкуса и контекста. Если нужно быстро объяснить команде — используйте гексагональную. Если важна формализация — чистая. Главное — сохранять независимость домена от инфраструктуры, что упрощает тестирование и замену внешних компонентов.