Какой паттерн DAO используете

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

Понимаете ли вы, где в вашем проекте проходит граница между бизнес-логикой и доступом к данным, и чем DAO отличается от Repository. Вопрос звучит как «какой вы используете», поэтому ждут не определение из книги, а реальный стек. Следом часто спрашивают, как вы тестируете этот слой.

Как отвечать

Дайте определение одной фразой: DAO прячет за интерфейсом работу с хранилищем, а сервис видит только методы вроде findById и save. Затем расскажите, как это устроено у вас:

• Spring Data JPA: интерфейс, наследующий JpaRepository<User, Long>, реализацию генерирует Spring. Производные запросы по имени метода, @Query для сложных случаев, Optional<User> вместо null;
• ручной DAO на JdbcTemplate или JdbcClient: когда нужен контроль над SQL, пакетные вставки или отчётные запросы, которые ORM строит плохо;
• jOOQ или MyBatis: типобезопасный SQL или маппинг через XML и аннотации, тоже за интерфейсом слоя данных.

Разницу с Repository объясните так: DAO ориентирован на таблицу и операции CRUD, Repository из DDD работает с агрегатом как с коллекцией доменных объектов. В Spring понятия часто сливаются, а аннотация @Repository ещё и включает перевод исключений в иерархию DataAccessException.

Добавьте про транзакции: @Transactional ставится на сервисный слой, а не на DAO, потому что одна бизнес-операция может задействовать несколько DAO. Для тестов слоя данных подходят @DataJpaTest и Testcontainers с настоящей базой, а сервис тестируется с моком интерфейса.

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

Пересказывают учебный пример с ручным Connection и не упоминают, что в реальном проекте соединениями управляет пул вроде HikariCP.

Не видят проблему N+1: ленивые связи JPA в цикле дают сотни запросов. Лечится JOIN FETCH или @EntityGraph.

Кладут бизнес-правила в DAO или, наоборот, пишут SQL в контроллере. Тогда слой перестаёт быть границей, и логику уже не проверить без базы.