java-architect - Архитектура Java и Spring Boot

Когда звать

• Когда Spring Boot-приложению нужны ясные границы домена, сервисов и репозиториев.
• Когда нужно проверить JPA-запросы, реактивные обработчики или настройку OAuth2 и JWT.

На какую Java рассчитан скилл

Java Architect посвящён приложениям на Java 21 LTS и Spring Boot 3.x. В его области применения есть JPA, Hibernate, WebFlux, OAuth2 и JWT. Это инструкции для агента, который меняет проект; отдельного Java-сервера скилл не запускает. Версия прочитанного файла - 1.1.0.

Прикладной сценарий - добавление нового REST-обработчика в приложение, где бизнес-правила, работа с базой и проверка доступа уже разделены. Скилл требует сначала разобраться в этих границах. Если назначение доменных моделей неясно, агент должен уточнить его до реализации, а не строить новый слой по догадке.

Как исходник разделяет работу

Сначала проверяются структура проекта, зависимости и конфигурация Spring. Далее агент проектирует модели по DDD и Clean Architecture. Для результата автор перечисляет сущности, DTO или records, сервис с транзакциями, интерфейсы репозиториев и контроллеры.

Слой данных проверяется отдельно. После изменения запроса инструкция требует выполнить проверку нужного модуля Maven. При падении интеграционного теста агент должен посмотреть SQL в журналах Hibernate, исправить запрос или mapping и повторить запуск.

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

Реактивность и безопасность

Для WebFlux автор приводит обработчик с Mono, ответом при отсутствии записи и проверкой входного тела через @Valid. Одновременно в ограничениях запрещено использовать блокирующий код в реактивном приложении. При задании на WebFlux полезно потребовать объяснить весь путь обращения к базе, а не только тип ответа контроллера.

Настройка безопасности включает Spring Security, порядок SecurityFilterChain и проверку JWT. После изменения безопасности исходник требует повторного полного запуска проверок. Показанный в файле пример конфигурации не следует переносить без разбора модели авторизации конкретного приложения.

Среди обязательных требований есть миграции Flyway или Liquibase, вынесенная конфигурация, OpenAPI и иерархия исключений. Автор запрещает пропускать валидацию и игнорировать транзакционные границы. Справочники охватывают настройку Spring Boot, реактивность, JPA, безопасность и тесты JUnit с Testcontainers и Mockito.

Что попросить в первой задаче

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

Итоговая проверка по автору выполняется Maven или Gradle, а покрытие от 85% оценивается по отчёту JaCoCo. Без настоящего отчёта эту цель нельзя считать достигнутой.

В паспорт внесены прочитанные SKILL.md и LICENSE одного коммита. Подключение всей коллекции описано в QUICKSTART; установку в Claude Code и совместимость с Codex мы не испытывали. Для отдельной проверки SQL пригодится SQL Pro.