Применяли ли вы архитектурные подходы, например чистую архитектуру или hexagonal architecture?

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

Был ли опыт, где архитектура что-то решала, или вы читали про круги на картинке. Смотрят на одну вещь: куда направлены зависимости и что знает домен про Spring, JPA и HTTP. Плюс трезвость: понимаете ли цену подхода и где он не нужен.

Как отвечать

Идея у обоих подходов одна: бизнес-логика в центре, остальное подключается к ней снаружи. Ядро объявляет порты (интерфейсы), адаптеры их реализуют: контроллер, репозиторий на JPA, клиент внешнего сервиса. Правило зависимостей: ссылки идут внутрь, домен не импортирует инфраструктуру.

Как это выглядит в Java-проекте:

• модули Gradle или Maven, где domain и application не зависят от spring-boot-starter-data-jpa: нарушение ловится компиляцией, а не на ревью;
• интерфейс OrderRepository лежит в домене, класс JpaOrderRepository в инфраструктуре, связывает их конфигурация Spring;
• сценарии тестируются без контекста Spring, на подменённых портах, и такой тест идёт миллисекунды;
• контроллер только превращает DTO в команду и обратно, транзакция начинается на уровне сценария.

Разница между названиями небольшая: гексагональная описывает порты и адаптеры, чистая добавляет слои внутри ядра (сущности, сценарии) и то же правило зависимостей. Честно скажите, где не применяли: в CRUD-сервисе без правил такой слой дорог и лишний.

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

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

Заводят пакеты domain, application, infrastructure, а внутри домена аннотации @Entity и @Transactional. Слои по названию папок, зависимости прежние. Проверка одна: собирается ли домен отдельным модулем.

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