Как устроена структура репозитория в проекте
Что проверяют
Работали ли вы с проектом шире своего пакета: понимаете ли, как он собирается, где лежат конфиги и миграции, почему модули разделены именно так. Следом часто спрашивают, что бы вы поменяли в этой структуре.
Как отвечать
Рассказывайте про свой проект и объясняйте не только что где лежит, но и почему:
- сборка: Maven или Gradle, в репозитории закоммичен wrapper (
mvnw,gradlew), чтобы версия сборщика у всех совпадала. Версии зависимостей в Gradle удобно держать вgradle/libs.versions.toml, в Maven вdependencyManagementродительскогоpom.xmlили через BOM; - модули: многомодульный проект (
<modules>в Maven,includeвsettings.gradle.kts), напримерapi,domain,infrastructure,app. Скажите, какую границу они держат: домен не зависит от Spring и базы, и сборка это проверяет; - пакеты: по слоям (
controller,service,repository) или по фичам (order,payment). В большом сервисе второй вариант обычно живёт дольше; - раскладка:
src/main/java,src/main/resourcesсapplication.ymlи профилями,src/test/java. Миграции Flyway по умолчанию лежат вdb/migrationна classpath, changelog Liquibase вdb/changelog; - тесты: юнит-тесты отдельно от интеграционных (Surefire и Failsafe с суффиксом
ITили отдельный source set в Gradle), интеграционные на Testcontainers; - инфраструктура:
Dockerfile,docker-compose.ymlдля локальных зависимостей, Helm-чарты, конфиг CI; - ветки: trunk-based с короткими ветками или GitFlow, и почему выбрали так.
Опирайтесь на реальный репозиторий и свои решения. Если структура досталась готовой, так и скажите и назовите, что в ней мешало.
Где спотыкаются
Пересказывают стандартную раскладку Maven, которую знает любой. Спрашивают про ваш проект, а не про документацию.
Не могут объяснить решение: «модулей пять, потому что так было». Лучше честно сказать, что считаете решение спорным, и объяснить почему.
Упоминают конфиги с паролями в репозитории как норму. Секреты живут в Vault или переменных окружения, а в application.yml только ссылки на них.