Рекомендации по реализации тестового задания (и не только): Java проект с REST API

Рекомендую писать проект современно: на Java это стек: Spring Boot + Spring Data JPA

Эмм, не совсем современно, хоть и популярно. Spring тянет с собой медленный reflection stack (все ключи бинов в итоге приводятся к строке). Современно -- это Dagger 2, который генерирует dependency injection во время компиляции, так что JIT проще, и можно скомпилировать код.

Вообще современно сейчас деплоить приложения в контейнерах легковесных, где довольно важно startup time. Отчасти из-за этого, по моим наблюдениям, Java в последнее время стали всё больше компилировать с помощью GraalVM. А там dependency injection ahead-of-time очень даже помогает.

Для веб сервера Jetty конечно очень популярен, не спорю, но я бы сказал сейчас современно писать на обёртках Netty (из-за async processing), например http4k или ktor для Котлина. Они тоже компилируются с GraalVM.

Для all-around frameworks (по крайней мере в Долине) популярны Dropwizard и Micronaut.

А JPA уже точно устарело. JOOQ самый популярный из современных, я бы сказал. Опять же таки из-за кодогенерации во время билда, как и Dagger.

• 6.4: Обновление в базе делается через update - не стоит смешивать JPA и DAO. апдейт делать не надо и сейв загруженного POJO также не надр - достаточно лишь изменить поля на необходимые значения, остальную работу сделает JPA. JPA и есть "паттерн".

• 7.5: Поля базы case insensitive, не пишите camelStyle - в обратных одинарных кавычках для мариядэбэ или майскл кейс сенситив, для оракла в двойных кавычках уейс сенситив, для мсскл в квадратных скобках кейс сенситив. поля можно указать в маппинге сущьностей. Поля кейс сенситив...

• 7.6: Таблицы я предпочитаю именовать в единственном числе. Исключение - users, т. к. user - зарезервированное слово - order и другие также лучше в множественном.

• 8.2: Я предпочитаю четкое разделение ролей на основе URL. Например, для админа URL содержит /admin - спорное утверждение, не имеющее отношения к праыильному выполнению тестового задания.

10.2: Проверяйте входные данные Primary Key при create/update в контроллерах. - этим может заниматься база данных, а Джава (слой данных) возбуждать исключение и возврвщать клиенту, например "бэд реквест". Без блокировки не существующих записей (да, это можно сделать) это не сделать консистентно, либо нужно изменять уровень изоляции транзакций, а это уменьшает масштабируемость приложения. Проще на это не обращать внимание, за вас сделает эту работу база данных и джпа/спринг.

• 11.1: JUnit-тесты очень желательны. Можно не делать 100% покрытие, только основные сценарии - junit тесты надо писать без поднятия контекста. С поднятием контекста - это лучше относить к интеграционным тестам. Почему? Потому, что тесты с контестом работают медленно, лучше мказать медленно поднимается контекст. Тесты дата-лейера тем более это интеграционные тесты. Как писать на спринге и не поднимать его в юнмт тестах? надо использовать библиотеку моков, например мокито.

• ОБЯЗАТЕЛЬНО: запусти mvn test - ошибок быть не должно - mvn verify тоже ошибки быть не должно при запуске интеграционных тестов.