Задание
|
Предыдущий урок
Видеоурок
|
2 из 3 уроков
Необходимо выполнить задание
|
Следующий урок
Оценка качества проверки ДЗ
|
Время выполнения задания: ~1-2 часа
Сложность: ⭐️⭐️ (максимум ⭐️⭐️⭐️⭐️⭐️)
Бонусы: 200
На вашем счету сейчас: 1 бонуса/ов
Use Case
микросервиса Delivery
На схеме показана Use Case диаграмма микросервиса Delivery. Нажмите на схему для увеличения.
Use Case микросервиса Delivery
Use Cases
Данное описание дано исключительно для понимания системы. В задании ориентируйтесь на бизнес-правила, указанные в самом задании.
Basket ->Создать заказ
Сервис Delivery создаёт заказ, вследствие оформления корзины. Сообщение "Корзина оформлена" будет приходить из Kafka, как только мы реализуем интеграцию с Basket.
Delivery -> Переместить курьеров
Разные курьеры имеют разную скорость перемещения. К примеру, если у курьера скорость равна 4, то за 1 такт курьер проходит 4 клетки, по X или Y, но суммарно не больше 4ех. В реальной системе мы бы получали координаты о самих курьеров. В нашей же системе будет Job, который имеет такт 1 секунду и при срабатывании такта - все курьеры перемещаются на сторону заказа с учетом их скорости.
Если курьер доставил заказ (=дошёл до точки), то в рамках этого же Use Case мы завершаем заказ, а курьер снова свободен и может брать новые заказы.
Этот Use Case мы будем запускать с помощью Job в 8 модуле.
Delivery -> Назначить заказ на курьера
Система сама распределяет заказы, она берёт первый по списку неназначенный заказ и ищет самого подходящего курьера. Основными критериями выбора являются:
- Время доставки курьером (расстояние от курьера до заказа деленное на скорость транспорта)
- Наличие свободных мест хранения, с учетом обьема заказа.
Этот Use Case мы будем запускать с помощью Job в 8 модуле.
Менеджер -> Получить всех курьеров
В любое время менеджер может отслеживать на карте местоположение курьеров, которые выполняют заказ. Он делает это в web-приложении Backoffice.
Менеджер -> Получить все незавершенные заказы (в статусе Created и Assigned)
В любое время менеджер может отслеживать на карте местоположение заказов. Он делает это в web-приложении Backoffice.
Domain Model
микросервиса Delivery
На схеме показана показана доменная модель микросервиса Delivery. Нажмите на схему для увеличения.
Задание
Легенда
Вы отвечаете за разработку микросервиса Delivery (доставка)
Подготовка
- Вы работаете в своем Git репозитории "delivery"
- Создайте ветку module-3
- Выполните задание в ней
Задача
- Перейдите в папку domain/model и создайте в ней папки:
- order
- courier
- Создайте в папке courier файл storage_place.go
- Реализуйте в файле storage_place.go структуру StoragePlace в соответствии с бизнес-правилами
- Скомпилируйте приложение
- Реализуйте Unit Test в достаточном количестве (хотя бы 1)
Бизнес-правила StoragePlace
- StoragePlace - это место хранения курьера (рюкзак, багажник и т.п.), он состоит из:
- Id (uuid, идентификатор)
- Должен быть уникальным
- Обязательный параметр
- Name (string, название места хранения: рюкзак, багажник и т.п.)
- Обязательный параметр
- TotalVolume (integer, допустимый объем)
- Не может быть меньше или равным 0
- Обязательный параметр
- OrderId (uuid, идентификатор заказа, который храниться в месте хранения)
- Необязательный параметр, если в месте хранения ничего не храниться, то nil
- Id (uuid, идентификатор)
- Место хранения может быть создано только при установлении названия и допустимого объема
- Место хранения должно уметь проверять, можно ли в него поместить заказ и возвращать да или нет. Если в месте хранения уже есть другой заказ или объем заказа превышает объем места хранения, то поместить новый нельзя.
- Место хранения должно уметь помещать в себя заказ, при этом заполняется OrderId. Поместить заказ в место хранение можно, только если: 1) его объем не превышает объем места хранения 2) в месте хранения нет другого заказа. В противном случае - ошибка.
- Место хранения должно уметь извлекать из себя заказ, при этом OrderId становиться пустым.
- Место хранения, в котором OrderId не установлен - считается пустым.
Технические требования
- Обеспечить корректное сравнение Entity по ID
Критерии оценивания
- Сущности соответствуют паттерну Entity
- Две Entity равны если их ID равны
- Инварианты не нарушаются
- Есть проверки на невалидные аргументы в методах
- Сущности покрыты Unit Test'ами (хотя бы 1)
По любым вопросам обращайтесь в комментариях к уроку или в Telegram
Если вы обнаружили ошибку или неточность в данном уроке, сообщите о ней в комментариях к данному уроку. Это поможет сделать курс лучше.