Структура проекта Spring Backend

Стандартная структура проекта помогает организовать исходный код и облегчает работу над разными проектами. С другой стороны, разные технологии имеют разные стандартные структуры и ожидания. Давайте рассмотрим структуру проекта веб-приложения на основе Java и Spring, которое предоставляет REST API для существующей базы данных.

Бэкэнд-технологиями являются Java, Spring, Hibernate и Docker, а git используется для контроля версий.

Проект Java управляется с помощью Maven, который дает базовую структуру проекта. Файл POM определяет проект Maven и показывает, что это каталог нашего проекта. Хотя проект Maven может включать в себя другие проекты Maven, это не обязательно для нас и усложняет вашу разработку. Каталог «src» содержит исходный код, который включает в себя как Java, так и конфигурацию. Целевой каталог является результатом процесса сборки и игнорируется.

tree -L 1 --charset=ascii
.
|-- architecture.png
|-- architecture.puml
|-- CHANGELOG.md
|-- docker-compose.yml
|-- Dockerfile
|-- infrastructure
|-- lombok.config
|-- pom.xml
|-- README.md
|-- src
`-- target
3 directories, 8 files

Остальные файлы и каталоги не имеют прямого отношения к Maven. Например, файл «lombok.config» настраивает зависимость Lombok для вставки аннотаций в сгенерированный код, и он не будет рассчитываться в тестовом покрытии. Эта конфигурация необходима для процесса сборки Maven и используется зависимостью. Файлы «README.md» и «CHANGELOG.md» описывают проект и его изменения. Таким образом, он следует стандартной структуре проекта Maven и расширяет ее несколькими конфигурациями.

tree -L 3 --charset=ascii src/
src/
|-- main
|   |-- java
|   |   `-- hu
|   `-- resources
|       |-- application.properties
|       `-- checkstyle.xml
`-- test
    `-- java
        `-- hu
7 directories, 2 files

Если вы проверите исходный каталог, то различаются основной и тестовый каталоги. Основные файлы будут упакованы в ваш артефакт, а тестовые файлы будут использоваться только во время сборки и тестирования. И исходный, и тестовый каталоги имеют каталог java. Ваш код организован в одну и ту же иерархию пакетов в этих каталогах java. Таким образом, ваши основной и тестовый файлы в конечном итоге окажутся в одном пакете, и вы сможете протестировать защищенные методы.

Каталог ресурсов в основных источниках содержит различные конфигурации. Во-первых, вы можете настроить Spring с помощью файла «application.properties». Здесь вы можете установить источники данных, определить уровень журнала и многое другое. Checkstyle используется для обеспечения соблюдения стандартов кодирования. Он проверяется Maven в процессе сборки. Кроме того, ваша среда IDE может форматировать ваш код и автоматически проверять наличие нарушений форматирования.

Hibernate был настроен с помощью файла свойств Spring. Поскольку для этого проекта схема базы данных была исправлена, дальнейшая настройка не требуется. Если ваше приложение имеет собственную схему базы данных, которая поддерживается вашей кодовой базой, вам следует использовать инструмент миграции базы данных, такой как Liquibase от Flyway.

В этом проекте база данных сотрудников выгружается из Репозитория реляционных баз данных, который является отличным источником баз данных с тестовыми данными для обучения.

Каталог «инфраструктура» содержит конфигурации и сценарии для локального запуска инфраструктуры разработчика. Если нашему проекту потребуются какие-либо службы, такие как базы данных, очереди сообщений или кэши, тогда этот каталог будет содержать файлы конфигурации. Есть файлы сценариев для запуска нашего сервера базы данных. Локальная инфраструктура разработки работает в Docker. Таким образом, вся непосредственная инфраструктура может быть запущена и инициализирована локально во время разработки.

В этом проекте скрипты дампа базы данных и запуска размещены в каталоге инфраструктуры. Есть два сценария оболочки для создания дампа базы данных и загрузки ее в локальный контейнер Docker. Файл .gitignore игнорирует дамп SQL и не позволяет вам его зафиксировать.

tree --charset=ascii -a  infrastructure/
infrastructure/
|-- dump_employee.sh
|-- sql
|   |-- employee-dump.sql
|   |-- employee.sql
|   `-- .gitignore
`-- start_database_in_docker.sh
1 directory, 5 files

Файл «dump_employee.sh» выполняет команду дампа в контейнере MariaDB и выгружает базу данных в смонтированный том. Каталог SQL — это смонтированный том. Контейнер Docker запускает образ MariaDB с пользовательской командой mysqldump. Поэтому MySQL Dump не следует устанавливать локально. К сожалению, дамп содержит неправильные параметры движка, которые меняются с помощью команды sed. Файл «employee.sql» содержит правильный файл дампа.

Файл «start_database_in_docker.sh» более интересен, хотя и выполняет одну команду. Переменная SCRIPT_DIR получает расположение этого скрипта. Это необходимо, потому что расположение файла employee.sql относительно этого скрипта. DOCKER_RUN_ARGS — это переменная списка, которая будет содержать наши параметры. Таким образом, вы можете легко отключить аргумент, комментируя. Это также делает вашу конфигурацию более читаемой, и вы можете сгруппировать параметры. Последняя строка просто запускает контейнер Docker со всеми аргументами.

#!/usr/bin/env bash

SCRIPT_DIR="$( cd -- "$( dirname -- "${BASH_SOURCE[0]}" )" &> /dev/null && pwd )"

DOCKER_RUN_ARGS=()
DOCKER_RUN_ARGS+=(--env MARIADB_ROOT_PASSWORD=secret)
DOCKER_RUN_ARGS+=(--env MARIADB_PASSWORD=secret)
DOCKER_RUN_ARGS+=(--env MARIADB_USER=employee)
DOCKER_RUN_ARGS+=(--env MARIADB_DATABASE=employee)
DOCKER_RUN_ARGS+=(--name employee-db)
DOCKER_RUN_ARGS+=(--publish 3306:3306)
DOCKER_RUN_ARGS+=(--rm)
DOCKER_RUN_ARGS+=(--volume $SCRIPT_DIR/sql/employee.sql:/docker-entrypoint-initdb.d/employee.sql:ro)

docker run "${DOCKER_RUN_ARGS[@]}" mariadb:10.6

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