Что такое гексагональная архитектура?

Что проверяют

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

Как отвечать

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

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

interface OrderRepository {
    public function save(Order $order): void;
}

Интерфейс лежит в домене, реализация на Doctrine в инфраструктуре, зависимость направлена внутрь. Отсюда и выгода: сценарий проверяется с простой заглушкой в памяти, без базы и HTTP, а замена библиотеки или транспорта не трогает бизнес-правила.

Где спотыкаются

Раскладывают каталоги по названиям слоёв и считают дело сделанным. Если сущность с аннотациями ORM и есть модель предметной области, а контроллер дёргает её напрямую, то гексагон нарисован только в дереве папок, а связность осталась прежней.

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

Тянут архитектуру туда, где предметной логики нет. Для тонкой обёртки над таблицами это лишние слои, лишний код и замедленная разработка. Окупается она там, где правила сложные и живут дольше, чем текущий фреймворк и текущая база.