Постановка задачи - Siyet/paw GitHub Wiki

Бизнес-процесс

Крупный продавец товаров, продает его на различных интернет-площадках. Сотрудник компании-продавца мониторит площадки на предмет наличия новых заказов. При появлении нового заказа сотрудник:

  1. Отправляется на склад и находит все товары
  2. Упаковывает товары в посылку, измеряет ее размеры и взвешивает ее
  3. Сотрудник перебирает различные сервисы почтовой доставки, указывает адрес доставки, габариты и вес посылки.
  4. Формируется перечень предложений по доставке
  5. Менеджер связывается с покупателем и согласовывает дату и сервис доставки
  6. Через выбранный сервис оформляется доставка, распечатывается этикетка посылки
  7. Коробка с заказом и наклеенной этикеткой доставляется к почтовому пункту

Не раскрытые вопросы: 1. Что делает сотрудник, если товара нет, или он просрочен? 2. Бывает ли самовывоз? Если да, то как это происходит?

Методы автоматизации

Автоматизацию, описанного процесса, предполагается реализовать в виде автоматизированной информационной системы (далее - АИС), состоящей из двух модулей:

  1. Веб-приложение - интерфейс взаимодействия пользователя с АИС, представляющее из себя сайт, открывающийся в веб-браузере
  2. Сервисы - интерфейсы взаимодействия с интернет-площадками реализации товаров и сервисами доставки. Декомпозиция сервисов

Технические аспекты

  1. Мониторинг заказов должен максимально приближен к real time
  2. Взаимодействие между двумя модулями при условии реализации их на разных технологиях
  3. OAuth 2.0 авторизация у большинства сервисов
  4. Имеется виртуальный сервер, ограничений по хостингу - нет
  5. Допускается, что модули АИС будут реализованы на разных языках программирования и технологиях
  6. Предполагаемая нагрузка неопределена, но решение предполагается отладить на конкретном продавце, а далее начать подключать всех желающих, поэтому выбор технологий должен предусматривать масштабируемость без основательного переписывания, как минимум в части, касающейся модуля сервисов.

Предлагаемые решения

  1. В качестве БД использовать MongoDB
  2. Change Streams, поддерживающиеся из коробки в MongoDB, позволят модулю сервисов асинхронно писать в БД все новые заказы и изменения по старым, а модулю Веб-приложения слушать изменения БД и в едином формате и месте, получать созданные/измененные заказы, ajax'ом отображать их пользователю в режиме real time
  3. Взаимодействие через популярную БД не накладывает никаких ограничений на stack технологий, на которых будут реализованы модули
  4. Модуль сервисов предполагается реализовать на stack'e JS (ES 6), NodeJS, Promises. Данный stack представляется оптимальным по соотношению производительности, порогу вхождения и стоимости дальнейшего сопровождения/развития. Ближайшие конкуренты:
  • Golang: средняя стоимость работ выше, чем на у JS (NodeJS), количество потенциальных исполнителей работ - меньше
  • PHP: средняя стоимость работ ниже, чем на JS, но и производительность - ниже, а реализовать асинхронный сервис - сложнее, также сложно найти качественных исполнителей работ под данный язык программирования
  • Python: крайне низкая производительность и более сложная масштабируемость относительно JS.

Автоматизируемые процессы модулем сервисов

  1. Постоянный мониторинг заказов на торговых интернет-площадках, в отсутствии real-time - максимально приближенный к real time цикличный запрос состояния заказов => При наличии новых заказов/изменений по существующим заказам, вносим их в БД
  2. Мониторинг БД, на предмет новых/измененных сведений о методе, сроках, цене и состоянию доставки => публикация сведений о доставке обратно на торговые площадки
  3. Мониторинг БД в ожидании новых запросов на доставку товара => опрос сервисов почтовой доставки на основании запроса, формирование перечня предложений по срокам и стоимости доставки => запись ответа на запрос в БД
  4. Мониторинг БД в ожидании запроса оформления доставки через конкретный сервис => формирование заказа на доставку, получение почтовой наклейки => прикрепление почтовой наклейки в качестве ответа на запрос