/Xsolla

test

Primary LanguageGo

Xsolla

Тестовое задание для Xsolla, основа - файл "Test task for Middle v2".

Предполагаемая реализация представляет 3 отдельных микросервиса - Shop, Kitchen, Delivery. Каждый из них включает в себе собственную бизнес-логику, с доменным структурами, взаимодействием с клиентом, репозиторий. Межсервисное взимодействие осуществляется асинхронно, через брокера сообщений NATS. В настоящий момент реализован основной функционал в сервисе Shop и частичный в сервисе Kitchen, планируется добавление сервиса Delivery. Сервисы дорабатываются, частично покрыты комментариям и todo.

Краткое описание общего функционала

Сервис Shop:

Создание заказа клиентом (MakeOrder, статус New) + задача -> Вывод созданных заказов для подтверждения (ListOrders) -> Подтверждение заказа администратором (ChangeOrderStatus, статус Confirmed) + задача -> По факту получения события об обновлении Cooking на InProgress обновление заказа на Cooking + задача -> По факту получения события об обновлении Cooking на Completed обновление заказа на Cooked + задача -> По факту получения события об обновлении Delivery на InProgress обновление заказа на Delivering + задача -> По факту получения события об обновлении Delivery на Completed обновление заказа на Completed + задача ->

Сервис Kitchen

По факту получения события о создании заказа происходит создание Cooking, статус New -> По факту получения события об обновлении статуса заказа до Confirmed происходит обновлении статуса Cooking до NeedToStart -> Вывод Cooking с NeedToStart для поваров (ListOfCooking) -> По факту принятия заказа поваром обновление статуса Cooking на InProgress (ChangeCookingStatus) + задача об обновлении в очередь в транзакции -> По факту завершения заказа поваром обновление статуса Cooking на Completed (ChangeCookingStatus) + задача об обновлении в очередь в транзакции

Сервис Delivery

По факту получения события о создании заказа происходит создание Delivery, статус New -> По факту получения события об обновлении статуса заказа до Cooked происходит обновлении статуса Delivery до NeedToGo -> Вывод Cooking с NeedToGo для курьеров (ListOfDelivery) -> По факту начала процесса доставки курьером происходит обновление статуса Delivery на InProgress(ChangeDeliveryStatus) + задача об обновлении в очередь в транзакции -> По факту завершения процесса доставки курьером происходит обновление статуса Delivery на Completed (ChangeDeliveryStatus) + задача об обновлении в очередь в транзакции

Комментарии относительно пунктов к описанию:

Context

  1. Создаваемый Order включает:
  • слайс структур Item. Item - совокупность информации о каждой заказанной позиции(кол-во, комментарии..) и содержит в себе структуру Product, которая содержит в себе информацию о продукте(предполагается использование энумов для полей Type и Name, тк мы ограничены в продаваемых продуктах). Комментарии доступны как общие (например, "Везите быстрее!!!), так и к каждой позиции (Например, "Уберите сыр из этого") В связи с наличием данных структур в ордере считаю возможным присылать на бек данные без price и currency - мы можем брать их из бд (Например, валюта - из указанной пользователем при регистрации(или привязанная к оплате с его платежной системы), а цена из Products).
  • структуру Address для определения местоположения заказчика. В дальнейшем валидируется в слое бизнес логики.
  • вспомогательную информацию: статус, время создания... 2,5,6. Ручка ListOfOrders для запроса ордеров с необходимым статусом.
  1. Ручка ChangeOrderStatus для обновления статусов ордеров.
  2. Реализовано в виде задач и последующей их обработкой в app.Proccess с отправлением событий в очередь.
  3. Реализовано в пакете internal (todo: скорее всего будет перемещено в сервис shop)

Non-functional requirements

Все кроме 6 пункта на текущей стадии разработки реализованы частично/предусмотрены.

Comments on the task

  1. В текущей реализации выбор используемых технологии основан на наличие опыта работы с ними. Строгой привязки нет, за счет достаточного разделения кода возможна замена любой из используемых технологии (брокер сообщений, бд, http на grpc). В дальнейшем возможно подключение метрик, сбор статистики (например, в кликхаус), добавление кэширование в редис и тп 2,6,8-9. todo
  2. Частичная реализация в виде кода, частичное описание в README.
  3. github
  4. README файл имеется, частичное описание в виде комментариев в сервисах.
  5. todo
  6. Имеются Dockerfile, todo docker-compose

Архитектура

Краткое описание директории проекта:

api: Состоит из конфигурации очередей сервисов, в дальнейшем возможно прото файлов и их генерации.

cmd: Включает в себя сервисы. Структура сервисов:

docker: Докерфайл

internal: Внутреннее строение сервиса:

adapters: Слои репозитория/Клиентов внешних API (при наличии) взаимодействия с ними/Клиент для брокера сообщений.

api: Слои для взаимодействия с клиентом через http/grpc.

app: Бизнес-логика сервиса

internal: Внутренние пакеты для общего использования в проекте.

libs: Вспомогательные пакеты.