system_description.md

Компоненты

1. Дашборд
   1. Для клиентов
      1. с заказанными или взятыми услугами
      2. Доступна кнопка создания нового заказа
   2. Для исполнителя
      1. Список активных, завершенных и отмененных задач
   3. Для менеджера
   4. Для отдела расходников
2. Пользователь
   1. Виды пользователей: менеджер, сотрудник отдела расходников, клиент, исполнитель
3. Заказ
   1. Форма создания
      1. Типы услуг заранее предопределены админами
      2. Срок выполнения заказа
      3. Автоматическая валидация заказа (?или запрос проверки менеджером в крайнем случае)
   2. Процесс работы над заказом
      1. Отметиться
      2. Отправка запроса на получение расходников в спец отдел
      3. Ожидание получения расходников
      4. Работа над заказом
      5. Составить бумажный отчет
      6. Уведомить клиента о выполнении, запросить подтверждение выполнения в виде подписи на отчете
      7. Отправить фотографию отчета с подписью клиента
      8. Перевести заказ в один из финальных статусов
   3. Отмена или провал заказа
      1. Клиенту предлагается создать копию заказа (новый заказ на другую дату). Из системы матчинга исключается прошлый исполнитель
      2. Заказ отправляется в отдел оценки качества работы (менеджерам) - в виде общего уведомления?
4. Платежная система
   1. Задача оплачивается, даже в случае отмены или провала исполнителем
   2. Скидочная система
      1. Зависит как от разовой суммы, так и от накопившейся
   3. Формула расчета стоимости (константная на данном этапе)
   4. Проверка счета (в тч на наличие средств)
   5. Оплата заказов
      1. Каждое воскресенье со счета клиента списывается сумма затрат на запрошенные задачи
      2. Формируется инвойс и отправляется клиенту
      3. Клиент оплачивает инвойс (любым выбранным им способом)
      4. Компания получает деньги на счет
      5. Клиент уведомляется об успешной оплате затрат
   6. Получение оплаты за заказ (для исполнителя)
      1. Производится раз в месяц (последний день месяца)
         1. Штрафы автоматически вычитаются
         2. Формируется инвойс
         3. Компания оплачивает инвойс
         4. Исполнитель получает уведомление об успешной/неуспешной оплате инвойса
      2. Заказ выполнен - 60% от суммы заказа
      3. Заказ отменен - 0%
      4. Заказ провален - штраф в 40 условных кото-единиц
   7. Страница с начислениями и списаниями денег
      1. Для клиента
         1. Ожидаемая сумма списания в конце недели
         2. Прошлые инвойсы и их статусы
      2. Для исполнителя
         1. Заработанная (за текущий период или месяц) сумма
         2. Прошлые инвойсы и их статусы
         3. Штрафы и их статусы
   8. Произвольное начисление денег исполнителю от менеджера
      1. Процесс тот же (через инвойсы), только триггерится вручную
      2. Нужна форма для менеджера по составлению инвойса (с обязательным указанием причины)
5. Матчинг
   1. На данном этапе - случайный подбор исполнителя
   2. После успешного создания заказа система сама выбирает исполнителя
   3. Исполнителю отправляется уведомления с деталями заказа
6. Регистрация исполнителей
   1. Заявка
      1. Необходимая информация должна включать номер счета (и желательно его проверку, например в виде списания и возврата минимальной условной единицы)
      2. Менеджер уведомляется о новой заявке
      3. Менеджер рассматривает заявку
      4. Менеджер отправляет кандидату в исполнители заранее составленный набор тестов
      5. Кандидат выполняет тесты или срок выполнения истекает
      6. Менеджер оценивает работу кандидата
      7. Менеджер составляет отчет по кандидату
      8. Менеджер оповещает кандидата о решении
      9. Менеджер добавляет информацию о новом исполнителе
      10. Характеристики кота декодируются в строку из 20 символов (ВАЖНО: сейчас проверка на уникальность не предусмотрена, поэтому это поле не может выступать как первичный ключ)
      11. Кандидат добавляется в пул исполнителей или в список непрошедших (для отсева или ограничения повторной подачи заявки)
      12. Ожидается 1000 заявок в день, нужно продумать автоматическую фильтрацию или невозможность отправить невалидную/нерелевантную заявку
          1. Ожидается, что будет не более 15 менеджеров
      13. Предусмотреть что-то типа rate limiting для обхода ddos атаки
7. Админка (все для менеджеров)
   1. Тест
   2. Дашборд с заявками
   3. Форма рассмотрения заявки
   4. Проверка заказа и связь с клиентом
      1. Заполнение формы с результатами оценки (эти формы должны быть доступны компании, те сотрудникам не менеджерам, либо менеджеры должны иметь возможность выгрузить их)
      2. Результаты оценки заказа отправляются как клиенту, так и исполнителю
8. Отдел расходников
   1. см 2.2
   2. ВАЖНО - Отдел расходников не контролируется, он собирает набор для заказа как угодно и имеет неограниченный доступ к кнопке выдано (НУЖНО ДОРАБОТАТЬ)
   3. Заказать печенье с предсказанием (ВАЖНО - сейчас не оптимально, заказывается печенье в единственном количестве, а не партией)
   4. 10-минутное ожидание печенья
   5. Добавление печенья в набор расходников
   6. Исполнитель уведомляется о готовности набора расходников и приглашается для того, чтобы забрать набор
9. Система ставок (для менеджеров)
10. Опциональна
11. Менеджер делает ставку на выполнение заказа (ставка + условие)
12. Нет контроля за выплатами результатов ставок
13. Если все ставки не зашли, банк уходит разработчикам
14. Система в "серой" зоне и никак не должна фигурировать в проекте (в плане выплат, расчеты производит система)
    1. Финансовые операции в "серой" зоне, но результаты в системе (условные единицы либо отсутствуют целиком, либо имеются в виде долей/процентов)
15. Нотификации
16. Практически каждое действие в системе должно иметь уведомление
17. Каждое действие с заказом должно иметь уведомление клиенту, исполнителю и менеджерам

Обоснование решений

• Проект - Монолит
  • потому что в проектах по-хорошему не работал с микросервисами и коммуникацией между ними. Монолит больше всего знаком
  • проект небольшой, стоит начать с монолита, но по возможности строить архитектуру с учетом возможного перехода на сервисы/микс (низкая связность, атомарность)
• Регистрация
• Дашборд
  • Единая точка входа в систему, в эндпойнте будет проверка на тип пользователя и редирект на соответствующий эндпойнт
  • Компонент, сильно зависимый от других компонентов
  • В основном для чтения
  • Включает блок основной информации (различается для типов пользователей)
  • Глобальная шапка-виджеты (баланс, последние инвойсы), создание заказа, настройки, перейти к инвойсам и тп
• Пользователь
  • Состоит из общей модели (или абстрактной модели), от которой наследуются остальные
• Заказы
  • Состоит из нескольких абстрактных моделей и модели, которая наследуется от них. Соответствующая логика в каждой абстрактной модели (изменение статуса, платежная логика и тп)
  • По началу имеют высокую связность с другими компонентами на уровне БД
• Платежная система
  • Необходимы проверки и валидации до создания/оплаты заказа
  • Также стоит проверять корректность введенных пользователями счетов
  • Никак не взаимодействует с системой ставок

Спорные моменты и вопросы

• Контроль за работой отдела расходников
• Проверка наличия средств для оплаты заказа
• Невозможность задать/увидеть сумму заказа до его создания/взятия в работу
• Регистрация сотрудников отдела расходников, новых менеджеров
• Будет ли форма взятия в работу заказа или подробная страница заказа для исполнителя?
  • На данном этапе исполнитель автоматически назначается
  • Будет ли у исполнителя возможность вручную выбрать заказ? Или подтвердить решение системы матчинга?
• Блокировать ли возможность взять новый заказ при наличии неоплаченных штрафов? Или при отрицательном балансе?
• Штрафы вычитаются при любом пополнении счета исполнителя? В том числе из инвойса от менеджера?
• Не проще ли отправлять ссылку на страницу заказа вместо копирования этой информации в нотификацию?
• Будет ли рейтинг выполнения заказов (в тч в зависимости от типа заказа)?
• Нужно ли составить пул тестов, чтобы они не повторялись и не хакались при повторной подаче заявки (если такая возможна)?
• Можно ли повторно подать заявку после отказа? Если да, то спустя какое период?
• Менеджеры сами выбирают заказ для проверки или им случайно предлагается заказ?
• Всегда ли доступна возможность связаться с клиентом при проверке заказа менеджером?
• Как должно работать перечисление банка ставок разработчикам?
• Есть ли ограничение на число активных задач исполнителя?

Заметки

• часть требований дана только для лучшего понимания того, что происходит в системе (например [US-040]). Если кажется, что требование непонятно к чему и куда, стоит его выписать отдельно и пояснить, почему оно кажется лишним.
• Планируемая нагрузка небольшая, не нужны слишком тяжеловесные решения и инструменты
• Части системы должны быть атомарны, чтобы изменения (или ошибки) в одной части не вели по цепочке к изменениям в другой. Это нужно для минимизации Time-to-Market
  • Также этот пункт важен, так как бизнес хочет быстро и надежно проверять новые гипотезы
• Не нужно углубляться в детали на этом этапе, достаточно общих сценариев и кейсов
• Механизма регистрации клиентов (пока) нет, для котов-тестировщиков видимо заводятся аккаунты админами