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

Слоистая архитектура выстраивает код стопкой Presentation → Business → Data, и зависимости идут сверху вниз вплоть до БД; гексагональная ставит доменное ядро в центр, а HTTP, БД и очереди подключает через порты (интерфейсы) и адаптеры (реализации).

Слоистая

• Слой зависит только от нижележащего — просто объяснить и начать.
• Проблема: бизнес-логика зависит от слоя данных, сущности подгоняют под ORM, тесты логики требуют БД.
• Частое вырождение — сервисы, которые один в один проксируют DAO, пока логика утекает в контроллеры.

Гексагональная (Алистер Кокберн, 2005)

• Входящие (driving) порты — интерфейсы use case'ов; их вызывают REST-контроллер, CLI, консьюмер очереди.
• Исходящие (driven) порты — интерфейсы, которые объявляет само ядро: PaymentGateway, OrderRepository; адаптеры Stripe и Postgres их реализуют.
• Зависимости направлены внутрь: ядро не импортирует ни фреймворк, ни драйвер БД — это Dependency Inversion на уровне архитектуры.
• Ядро тестируется с in-memory адаптерами, без сети и БД; смена хранилища затрагивает один адаптер.

Когда что

• CRUD, прототип, маленькая команда → слои: меньше интерфейсов и маппинга.
• Сложный домен, много интеграций, долгий срок жизни → гексагон. Onion и Clean Architecture — его вариации с тем же правилом зависимостей.
• Цена гексагона — маппинг DTO ↔ домен ↔ модель БД на каждой границе.

Коротко для собеседования

Главное отличие — направление зависимостей: в слоях логика зависит от базы данных, в гексагоне инфраструктура зависит от интерфейсов ядра. Слои проще для CRUD и прототипов, гексагон окупается при сложном домене и многих интеграциях ценой маппинга на границах.