Основная задача проекта: Разработать приложение для управления коворкинг-пространством. Приложение должно позволять пользователям бронировать рабочие места, конференц-залы, а также управлять бронированиями и просматривать доступность ресурсов.

Т.е. все то, что было описано и проделано в:

• StepOne;
• StepTwo;

Чтобы не прыгать по описаниям вспомним, что на первом шаге мы использовали только возможности JAVA. На втором шаге мы добавили новые технологии (но, данные все еще возвращались в консоль и взаимодействие происходило через CLI):

• JDBC;
• Миграционный фреймворк для БД - Liquibase;
• Docker для БД (описание использования и примеры для Spring Boot, отличается от текущего);
• Test-containers (описание использования и примеры для Spring Boot, реализация отличается от текущего);

• Репозитории должны писать ВСЕ сущности в БД PostgreSQL (документация);
• Идентификаторы при сохранении в БД должны выдаваться через sequence;
• DDL-скрипты на создание таблиц и скрипты на предзаполнение таблиц должны выполняться только инструментом миграции Liquibase (Liquibase GitHub);
• Скрипты миграции Liquibase должны быть написаны в нотации XML или YAML (SQL);
• Скриптов миграции должно быть несколько:
  • Создание всех таблиц;
  • Предзаполнение данными;
• Служебные таблицы должны быть в отдельной схеме;
• Таблицы сущностей хранить в схеме public запрещено (создать свою схему);
• В тестах необходимо использовать test-containers (short tutorial);
• В приложении должен быть docker-compose.yml:
  • В котором должны быть прописаны инструкции для развертывания postgres БД в докере;
  • Логин, пароль к БД должны быть отличными от тех, что прописаны в образе по-умолчанию;
  • Приложение должно работать с БД, развернутой в докере с указанными параметрами;
• Приложение должно поддерживать конфиг-файлы:
  • Всё, что относится к подключению БД;
  • Настройки и инструкции к миграциям, должно быть сконфигурировано через конфиг-файл;

• Взаимодействие с БД идет по средствам Hibernate (Hibernate Tutorial);
• Взаимодействие с приложением должно осуществляться через отправку HTTP запросов;
• При запросах и ответах сервлеты (servlets) должны принимать JSON и возвращать JSON;
• Для сериализации и десериализации необходимо использовать библиотеку Jackson (статьи);
• Использовать понятное названия эндпоинтов (endpoint);
• Возвращать разные статус-коды (HTTP-коды);
• Добавить DTO;
• Для маппинга сущностей в DTO использовать MapStruct (Quick Guide);
• Реализовать валидацию входящих DTO;
• Реализовать аудит ключевых действий пользователя через AOP (введение в AspectJ);
• Реализовать через AOP логирование выполнения ключевых методов (с замером времени выполнения) (short intro);
• Покрыть сервлеты тестами (спорный момент);

• Функциональные требования выполнены полностью.
• Технические требования выполнены полностью.

Данная версия приложения взаимодействует с пользователем (сервисом или другим приложением) по средствам HTTP-запросов и использует в своей реализации Servlet API. Значит нам нужен или сервер приложений (Payara, GlassFish) или контейнер сервлетов (TomCat) для запуска нашего приложения. Используем TomCat. Скрипты Liquibase при первичном старте создадут необходимые предзаполненные таблицы.

Структура проекта (это не Spring проект, но слоистую структуру можно применять где угодно, отсюда и названия):

• annotation - аннотации для аудирования и логирования;

• aspects - аспектные классы (аудит, логирование, транзакции);

• config:

  • connection - папка содержит классы отвечающие за связь с БД;
  • liquibase - папка с классом управляющим работой миграционного фреймворка Liquibase;
  • util - папка с конфигуратором приложения и Hibernate;

• core:

  • controllers - классы управляющие манипуляцией с сущностями на 'верхнем' уровне приложения;
  • dto - классы для передачи данных со слоя на слой;
  • mapper - классы сопоставители;
  • model:
    • criteria.expander - класс дополнение для формирования запросов при помощи Criteria API (см. ком-ии внутри класса);
    • database:
      • audit - класс работающий с функционалом аудирования;
      • entity - основные рабочие элементы проекта с которыми происходят манипуляции (залы/рабочие места, слоты времени для резервирования, пользователи, записи о резервировании содержащие сведения о том, что, когда, и на сколько было зарезервировано);
      • repository - классы для взаимодействия с БД;
    • service - классы отвечающие за обработку запросов с уровня контроллеров;

• exceptions - папка с исключениями;

• filter - фильтр задающий кодировку при обращении к сервлетам;

• security - классы для работы с JWT аутентификацией;

• servlets - классы HTTP интерфейса;

• validates - класс валидатор (для проверки входящих DTO);

• AppContextBuilder - класс формирующий общий контекст приложения;

• resources:

  • db/changelog - файлы миграции Liquibase;
  • application.properties - файл настроек (см. комментарии);
  • hibernate.cfg.xml - укороченный конфигуратор Hibernate (основная нагрузка на Java конфигурации);
  • log4j.xml - конфигурация логера;

• Классы 92% (234/252);
• Методы 84% (742/874);
• Строки кода 73% (2122/2904);

Тестирование проводилось в двух вариантах:

• тестирование с применением Test-containers (слой репозиториев и слой сервисов);
• тестирование с применением фреймворка Mockito и AssertJ (слой контроллеров и сервлеты);

Наиболее интересными моментами в тестировании сервлетов является тот факт, что разработчики того же Mockito не рекомендуют использовать заглушки на классы, которые мы (разработчики) сами не создавали (т.е. не mock-ать чужие библиотеки, возможно я и ошибаюсь):

Remember
Do not mock types you don’t own
Don’t mock value objects
Don’t mock everything
Show love with your tests!

Любопытным показался вариант использования метода doAnswer см. тест. Пара статей по вопросу применения doAnswer.

Во всех реализациях приложения есть задача вывода свободных слотов на конкретную дату, при это не уточняется в каком формате. Мы решили выводить информацию в формате коллекции - на конкретную дату будет существовать список наших Places (рабочих мест и залов) и каждый из них будет иметь ограниченное количество слотов, которые можно забронировать (возможно останутся и свободные) - вот их мы и выводим. Если у Place (места/зала) нет резервирования на конкретную дату - все слоты свободны - логично. Реализацию данного вывода берет на себя метод *.findAllFreeSlotsByDate(LocalDate date) класса ReservationService.java. И тут полет фантазии на реализацию обширен, просто на коллекциях и циклах (многословно и запутанно) или с применением StreamAPI.

Один из вариантов (можно сравнить с текущей реализацией):

List<Reservation> reservationList =
            reservationRepository.findReservationByDate(LocalDate.of(2029, 7, 28)).get();

    Map<Long, List<Long>> allFreeSlotsByDay = new HashMap<>();

    List<Long> allAvailableSlot = slotRepository.findAll().stream()
                                                          .map(Slot::getSlotId)
                                                          .toList();

    var placeReservationMap=
            reservationList.stream()
                           .collect(Collectors.groupingBy(Reservation::getPlace))
                           .entrySet().stream()
                                      .collect(Collectors.toMap(eKey -> eKey.getKey().getPlaceId(),
                                                                eValue -> eValue.getValue().stream()
                                                                                           .map(r -> r.getSlot().getSlotId())
                                                                                           .collect(Collectors.toList())));

    placeReservationMap.forEach((key, value) -> {
        List<Long> freeSlotByPlace = new ArrayList<>(allAvailableSlot);
        value.forEach(freeSlotByPlace::remove);
        allFreeSlotsByDay.put(key, freeSlotByPlace);
    });

    System.out.println(allFreeSlotsByDay);

Адрес хоста стандартный для локальной машины (порт исходя из настроек TomCat): http://localhost:8081

Естественно при развертке приложения в контейнере, или в локальном TomCat, в полном адресе запроса может появиться имя приложения (папки где оно развернуто), например cw и тогда между адресом хоста и endpoint-ом появится дополнение, например:

http://localhost:8081/cw/cw_api/v1/places/

Не забываем про это!

Для тестирования приложения можно использовать Postman (простая проверка - запустилось или нет обратиться к HelloWorld странице приложения): http://localhost:8081/cw_api/hello

Приложение для аутентификации используем JWT ключ, посему не забываем его применять. После авторизации сервис (пользователь) получает его в ответ, пример:

Далее при формировании запроса через Postman выбираем тип аутентификации и добавляем полученный JWT ключ в соответствующее поле:

После разработки приложения, и тестирования его в локальном окружении, у нас появилась мысль упаковать его в Docker-образ. Более подробно процесс описан в разделе docker-practice. Рассмотрено несколько способов:

• с применением уже готового TomCat образа без возможности быстрой сборки того;
• с применением меньшего образа TomCat и внедрением переменных окружения;
• с оптимизацией размера образа и размещением его на DockerHub;

Естественно мы не забыли про docker-compose - теперь приложение и БД можно быстро развернуть практически на любой машине. Отличие текущего docker-compose файла от более старой его версии, примененной для предпоследней версии приложения, это размещение Volumes не в рабочей папке приложения запускающейся из Intellij IDEA, а размещение их внутри виртуальной машины Docker-a: