Реализуем функционал банковского приложения, с базовой структурой БД, можно ознакомится в visual paradigm, в ченджлогах и описании каждого микросервиса Проект рассчитан на студентов, успешно завершивших этап Pre-Project в Kata Academy.
Java 17
Spring Boot 2
- для более быстрой разработки бэка.
Maven
- как инструмент сборки.
PostgreSQL
- как БД.
Spring Data
- для облегчения работы с БД.
Hibernate
- как ORM.
Lombok
- чтобы не писать boilerplate-код, используем на проекте Lombok.
Mapstruct
- для маппинга, Mapstruct.
Liquibase
- для миграции БД, Ссылка 1. Ссылка 2.
Openfeign
- для использования эврика-сервера, и фейн-клиентов для общения между микросервисами.
Springdoc-openapi-ui
- Swagger.
Junit5
- для тестов.
Mockito
- для тестов.
Spring Test
- для интеграционных тестов.
Spring-security
- для аутентификации и авторизации.
Docker
- для поднятия контейнеров.
Postman
- тестирования через запросы.
Visual paradigm
- для проработки базовый структуры БД и генерации ченджлогов.
MVP - API (полностью описанное в Swagger). Работать с таким API можно будет через веб-интерфейс Swagger и Postman.
Проект основан на микросерверной архитектуре. А каждый микросервис выстроен по архитектуре REST. Главный принцип следить, чтобы по логике одинаковые классы лежали в одном пакете.
Слои:
config
конфигурационные классыentity
сущности базы данныхdto
специальные сущности для передачи/получения данных в/с апиrepository
dao-слой приложения, реализуем в виде интерфейсов Spring Data, имплементирующих JpaRepository.service
бизнес-логика приложения, реализуем в виде интерфейсов и имплементирующих их классов.controller
обычные и rest-контроллеры приложения.validator
валидаторов.exception
эксепшнов.handler
хэндлеров.
Доступы. Если ты читаешь это, значит доступ к проекту у тебя уже есть
- загрузи проект себе в среду разработки
- изучи весь проект - начни с pom, properties файлов и конфигурационных классов, так же посмотри visual paradigm
- в докере подними БД в командной строке запущенной от имени администратора надо ввести
docker run --name postgres -e POSTGRES_PASSWORD=password -e POSTGRES_USER=user -e POSTGRES_DB=postgres -p 5434:5432 -d postgres
, где --name имя контейнера, -e POSTGRES_PASSWORD= пароль БД, POSTGRES_USER= логин БД - так же в БД нужно создать 7 схем: account, anti_fraud, auth, history, profile, transfer, public_bank_information
- добейся успешного запуска своего микросервиса
Таск-борд строится по принципу Kanban - он разделён на столбцы, каждый из которых соответствует определённому этапу работы с задачей:
Backlog
задачи на новый функционал, корзина функционала приложения. Здесь можете создавать карточки на таски, которые считаете необходимымиTODO
задачи, требующие выполненияIn Progress
выполняемые в данный момент задачи, обязательно должны иметь исполнителяCross-review
задачи на этапе перекрёстной проверки студентамиFinal Review
задачи на проверке у техлидаClosed
выполненные задачи
У каждой задачи есть теги:
Feature/Refactor
- новый функционал или переработка существующегоBug
- таска на исправление бага до или после тестированияReworking
- таска на исправлении замечаний после кросс или файнал ревьюBacklog, ToDo, InProgress, CrossReview, FinalReview
- этапы прохождения задачи по борде
- в графе
TODO
на таск-борде выбери карточку с задачей и назначь её себе для исполнения - загрузи себе последнюю версию ветки
develop
- создай от
develop
свою собственную ветку для выполнения взятой задачи. Свою ветку назови так, чтобы было понятно, чему посвящена задача. В начале имени ветки проставь номер задачи с Gitlab. Например,bk-313
- выполни задачу, обязательно сделай юнит-тесты на методы и, вызови в мавне clean-install, так же после прогона тестов и clean-install, запусти проект и кинь, хотя бы один запрос, если всё ок, залей её в репозиторий проекта,
- создай на своей ветке merge request, в теле реквеста укажи
Closes #здесь-номер-таски"
. Например,Closes #313
- перенеси задачу в столбец
Cross-review
На этапе кросс-ревью студенты проверяют задачи, выполненные друг другом. В случае, если к коду есть замечания, проверяющий пишет замечания в мердж реквесте и оставляет комментарий в карточке. Если к коду претензий нет, проверяющий студент ставит к карточке лайк.
Каждая карточка (студенческая задача) должна быть проверена как минимум 2 другими студентами и одобрена ими (т.е. собрать не менее 2 лайков).
Только после этого карточку можно переносить в столбец Final Review
.
Затем код проверяет техлид (ментор) и в случае обнаружения ошибок ставит тег Reworking
и переносит её в столбец InProgress
.
Если всё ок - merge request принимается, ветка студента сливается с основной веткой проекта, а карточка переносится в столбец Closed
.
- сделайте себе понятные никнеймы (имя + фамилия) в Git. Не хочу гадать, кто, где и что писал.
- для каждого класса и (желательно) методов пишите комментарии в формате Javadoc:
- над классом: что это за класс, зачем нужен. Описывайте поля.
- над методом: что делает, какие параметры принимает (и что это такое), что возвращает.
- над приватными методами не нужны комментарии в формате javadoc.
- свободно создавайте собственные вспомогательные классы в пакете Util - типа утилиток для страховки от null и типа того.
- в REST-контроллерах пользоваться аннотациями Swagger - причём как сами контроллеры в целом, так и их отдельные методы. Посмотрите пример в проекте
- на полях сущностей можно и нужно расставлять констрейнты для проверки формата, длины введённых значений, проверки чисел на положительность и т.д.
- пишите Commit message как можно более подробно! На русском языке.
- все контроллеры и их методы нужно сразу описывать аннотациями.
Если в процессе разработки вы пришли к пониманию того, что требуется создать какую-то ещё сущность - создавайте карточку в Open
, согласуйте ее с тимлидом и вперёд
-
В каждый метод необходимо добавить логирование с описанием произведенной операции на уровне info(только в крайнем случае, чтобы не засорят логи)
-
Если объект не найден, вывести сообщение уровня error ("not found" или "does not exist") с описанием произведенной операции и выбросить EntityNotFoundException.
-
Если бросаете эксепшен, то логируйте с сообщением эксепшена и в уровне error.
Созвоны проходят по средам и пятницам в оговорённое время. Регламент:
- длительность до 15 минут
- формат: доклады по 3 пунктам:
- что сделано с прошлого созвона
- какие были/есть трудности
- что будешь делать до следующего созвона
- техлид (ментор) на созвонах код не ревьюит
Любые другие рабочие созвоны команда проводит без ограничений, т.е. в любое время без участия техлида. Договаривайтесь сами :)
пока используем spring-boot-starter-security