Требования к системе: "Корпоративная библиотека"

Функциональные требования

Цели

• Библиотека корпоративная - работает только для авторизованных пользователей (basic авторизация. опционально - можно заменить на jwt)
• Должно быть предусмотрено 2 роли - пользователь и администратор. Должен быть пред-создан пользователь admin1/admin1, admin2/admin2, user1/user1, user2/user2

Пользователь

• Библиотека должна иметь возможность для поиска книг (с возможностью фильтрации и сортировки как минимум по названию книги и isbn).
• Библиотека должна иметь возможность просмотра подробной карточки книги и списка комментариев других пользователей по ней. Комментарии должна быть возможность сортировать и фильтровать по оценке
• Библиотека должна иметь процесс отзывов для книги пользователями с возможностью оставить оценку и комментарий. Один пользователь может оставить только один отзыв по книге. Оценка обязательна. Комментарий - нет. Свой отзыв можно обновлять и удалять
• Библиотека должна иметь процесс "добавления" книг пользователями дающий возможность предложить новую книгу в библиотеку, при необходимости (после проверки предложения администратором) внести изменения в предложение.

Администратор

• Библиотека должна иметь возможность для поиска книг (с возможностью фильтрации по тем же полям, что и пользователь)
• Библиотека должна иметь возможность удалять отзывы пользователей по книгам. Не должно быть возможности создания/редактирования отзывов
• Библиотека должна иметь возможность отправлять предложенную пользователями книгу на доработку (с комментарием) и подтверждать предложенные книги после прохождения проверки

API

• В API для книги и комментария должны быть доступны КАК МИНИМУМ следующие поля для всех ролей:

  book (книга)
    image_url
    isbn
    isbn13
    name
    original_publication_year
    original_title
    small_image_url
    title
    lang_code
    rating_count -- кол-во отзывов
    rating_avg -- средняя оценка в отзывах
  review (отзыв)
    commentadmin1
  rating (оценка)

• API для предложения новой книги для каждой роли - продумать полностью самостоятельно
• приложение должно предоставлять OpenAPI (swagger) спецификацию своего REST API

Миграция данных

В "новое" приложение корпоративной библиотеки необходимо смигрировать данные "старого" приложения библиотеки:

• Данные старой библиотеки предоставлены в виде csv файлов (см. /data)
• Модель данных новой и старой библиотеки частично не совпадает - маппинг необходимо сделать самостоятельно
• Необходимо разработать процедуру миграции данных (можно через Liquibase. Желательно самостоятельно посмотреть SpringBatch для адекватной скорости миграции)
• Для миграции можно создавать доп. таблицы при необходимости

Нефункциональные требования:

Нагрузка

Текущий объем данных:

• book: ~10 000
• comment: ~1 000 000

Через 5 лет ожидаемый объем данных:

• book: ~100 000
• comment: ~10 000 000

SLA (Service Level Agreement):

При запуске приложения и DB на сервере 4vСPU, ssd 100gb, 16gb ram медианное время ответа API должно быть меньше либо равно:

• список книг (с фильтрацией) - 6 сек
• список книг (с сортировкой) - 2 сек
• список книг (без сортировки/фильтрации) - 2 сек
• прочие - 0.5 сек

QA (Quality Assurance)

Интеграционные тесты

Приложение должно содержать интеграционные тесты проходящие как минимум следующий сценарий полного жизненного цикла книги

1. user1 просматривает список книг. фильтрует по имени. находит несколько книг. заходит в карточку книги. оставляет отзыв с оценкой >0. выходит в список книг и повторяет поиск - видит измененный рейтинг. заходит в "предложенные книги" - создает новое предложение и отправляет его на согласование админу. в "предложенные книги user1 видно его предложение и статус"
2. user2 заходит в "предложенные книги" - его список пуст
3. admin1 заходит в "предложенные книги" -- находит предложение от user1. пишет комментарий о необходимости внесения правок и отправляет предложение на доработку
4. user1 вносит запрошенные администратором изменения и возвращает предложение обратно администратору
5. admin1 - согласовывает предложенную книгу
6. книга становится доступна в списке книг и для всех пользователей. проверить под user1 и под user2

P.S.

Дополнительные комментарии:

• В данной задаче мы тренируемся разрабатывать приложение отображающее "реальный" объем данных - это автоматически исключит возможность писать "учебный код" и заставит нас потренироваться в проектировании приближенной к реальности архитектуры (чтобы хватало и RAM и скорости ответа - надо будет подумать и над пагинацией, и над индексами, и над устройством API и пр.)
• В данной задаче мы использовали реальный набор данных https://www.kaggle.com/code/bshirude2/goodreads-content-based-book-recommendation/input, который немного упростили в соответствии с целями нашего задания и приложили в репозиторий в виде csv файлов
• В данной задаче мы тренируемся делать приложения с "процессами", в которых чаще всего есть несколько ролей и движение по стадиям процесса (подумайте как хранить текущую стадию процесса. какая роль в какой стадии имеет возможность редактирования, а в какой стадии нет).
• В данной задаче несколько администраторов могут начать редактировать сущности одновременно - используйте optimistic locking через @Version в hibernate, чтобы обработать эту ситуацию
• В данной задаче ожидается реализация приложения на SpringBoot, java 17, hibernate, Spring Data JPA, миграции liquibase, db - postgresql. вся инфраструктура (например, postgresql) для локального запуска должна быть описана в docker-compose
• В данной задаче при необходимости можно и нужно добавлять доп. поля и сущности, но только для реализации описанных выше бизнес-требований. собственные бизнес требования придумывать при реализации не следует. т.е. мы должны понять потребность бизнеса исходя из постановки и добавить только необходимый для ее реализации минимум