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

Question

Accepted Answer

Домен в центре и не зависит ни от чего внешнего. Он объявляет порты — интерфейсы на своём языке: входящие (сценарии использования) и исходящие (OrderRepository, PaymentGateway). Адаптеры снаружи реализуют их: REST-контроллер, JPA-репозиторий, клиент Kafka. Все зависимости направлены внутрь. Слоистая: контроллер → сервис → репозиторий, и бизнес-логика зависит от слоя данных Гексагональная переворачивает эту стрелку через DIP Домен тестируется без БД и фреймворка — подменой адаптеров Чистая и луковая архитектуры — варианты той же идеи Проблема слоистой архитектуры. Сервис зависит от репозитория, а репозиторий — от ORM. Бизнес-правила обрастают аннотациями JPA, исключениями драйвера, DTO фреймворка. Сменить базу или протестировать логику без неё трудно. Порты и адаптеры (Алистер Кокберн): - домен — сущности и правила, без импорта фреймворков; - входящие порты — сценарии: PlaceOrder, CancelOrder; - исходящие порты — что домену нужно от мира: Orders, PaymentGateway, Clock; - входящие адаптеры вызывают сценарии: REST, консьюмер очереди, CLI, тесты; - исходящие адаптеры реализуют исходящие порты: JPA, HTTP-клиент, Kafka-продюсер. Плюсы: домен тестируется быстрыми юнит-тестами с фейковыми адаптерами; инфраструктура заменяема; бизнес-код читается без шума. Цена: больше интерфейсов и маппинга между доменными объектами и сущностями БД; для CRUD без правил это избыточно. Критерий хорошего порта: он сформулирован в терминах…

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

Подробно

Что хотят услышать

Частые ошибки

Связанные вопросы

Подсказки на собеседовании — в реальном времени