Как стать автором
Обновить

Система управления складом с использованием CQRS и Event Sourcing. Постановка требований

Время на прочтение 4 мин
Количество просмотров 4.7K
image

В последнее время стала популярна концепция Omnichannel, когда чтобы улучшить качество обслуживания клиентов, различные каналы продаж интегрируются в один. И не важно как и где совершается продажа, для продавца имеет смысл объединить все каналы сбыта для того, чтобы выполнить заказ. На практике это означает, что неважно клиент пришел к вам оффлайн, сделал заказ на сайте, в мобильном приложении или в телефонном режиме — вы должны использовать все доступные средства для его выполнения. И для вас, как для продавца, каждый отдельный канал не должен представлять большой разницы. Презентация omni channel на примере Франкфуртского аэропорта (англ.).

Для интеграции описанной выше, со стороны продавца очень важно иметь возожность интегрировать уровни запасов товаров. Потому что инфраструктура розничной торговли может быть достаточно сложной и объединять внешние склады, магазины, магазины с возможностью заказа товаров в магазин (store pick-up), дропшиппинг (схема торговли, при которой Вы продаёте изделия фирмы-поставщика, которая сама пересылает их покупателю от Вашего имени, а Вы только принимаете от покупателя деньги).


image

Так как мы занимаемся разработкой фреймворка, а не какого-то конкретного решения с интеграцией «под ключ» для определенного бизнеса, набор требований для нас получился достатчоно широким.
В число основных требований входит:
  • Система управления запасами не должна быть бутылочным горлышком во время чекаута, когда совершается заказ. Т.е. должны отсутствовать синхронные проверки актуальности наличия продуктов на каждом из складов, и потенциальные блокировки им сопутствующие.
  • Система должна поддерживать асинхронную обработку заказа, при которой само создание заказа не будет являться операцией изменяющей состояние системы. А будет только регистрироваться команда, которую нужно будет обработать впоследствии. Таким образом критическая по времени выполнения операция размещения заказа будет проходить очень быстро и без каких-либо блокировок. Такую реализацию можно увидеть, например, у Amazon, когда после успешного размещения заказа и оплаты покупателю через время может прийти письмо уведомляющее, что система не может выполнить заказ, потому что товаров на складе не достаточно и возвращает деньги. С одной стороны это может ухудшить впечатления покупателя, но для продавцов с большими складами, которые совершают сотни тысяч продаж в день — такой риск вполне оправдан ради ускорения процесса размещения заказа.
  • Система должна предоставлять различные алгоритмы доставки товаров из нескольких складов для конечного пользователя. Например, в простейшем случае это может быть доставка по приоритетам, где каждому из источников доставки указывается приоритет, и система будет идти по этому приоритету пытаясь взять максимум товаров для выполнения заказов с каждого из складов. Более слоные алгоритмы подразумевают определение минимальных трат на доставку (Minimal Shipping Cost) отдельно для клиента и для продавца.
  • Система управления запасами должна предоставлять значение некого агрегированного стока для конкретного товара в рамках текущего контекста, на фронтенде для покупателей. И это значение принимается во внимание при продаже товара или при оценке закончился ли у нас в наличие товар или еще нет. Это нужно для того чтобы в рантайме не считать стоки по каждому из продуктов, особенно на таких критически важных страницах как старница категории продуктов это может занять достаточное время и замедлить производительность.
  • Система должна поддерживать механизм резерваций, когда продавец может зарезервировать продажу, например, для своего оптового клиента, которая должна выполниться в определенный срок. После этого зарезервированные продукты не могут быть проданы через другие каналы продаж другим клиентам.
  • Система должна предоставлять механизм контроля загруженности складов и других физических мест размещения товаров. Чтобы иметь возможность спланировать и организовать логистику и доставку товаров, когда запасы нужно будет пополнить.
  • Для поддержки предыдущего пункта также должны вводиться специальный набор состояний для продукта, чтобы решать такие задачи: товар продан, но еще не отгружен со склада, соответсвенно еще занимает место на складе, и мы не можем на этот склад завезти новый товар. Также товар, который был возвращен покупателем не всегда может сразу вернуться в сток. Иногда товар возвращается по принчине неисправности или брака, соответсвенно такой товар следует обрабатывать отдельно.
  • Поддержка дропшиппинга
  • Система должна предотавлять гибкую возможность маппинга физических складов на каналы продаж (Sales Channel). Об этом пункте отдельно


Маппинг физических складов и хранилищ на каналы продаж


image

На данной диаграмме отображены различные возможности маппинга физических складов, на которых находится товар на каналы продаж. Под каналами продаж подразумеваются способы доставки товаров на рынок и последующей их реализации. Например, в терминах Magento это может быть Website, но с появлением B2B отдельным каналом продажи может быть оптовый клиент для которого у вас есть отдельная скидка, и который отдельно может с вами торговаться. В этом случае каналом продажи будт являться Customer Group. Также хорошим примером канала продажи может являтсья страна или регион.

Как вы можете заметить на данной диаграмме физические склады объединяются в виртуальную агрегацию, которая в свою очередь присваивается конкретному каналу сбыта. При этом один физический склад может обслуживать более чем 1 канал продаж, а в рамках канала продажи может объединяться сток из более чем одного склада. Это позволяет достичь максимальной гибкости, а также, если понадобится, вводить новые каналы продаж и сопоставить им существующие стоки.

Magento MSI (Multi Source Inventory)


Данная статья является первой статьей в цикле «Система управления складом с использованием CQRS и Event Sourcing» в рамках которого будет рассмотрен сбор требований, проектирование и разработка системы управления складом на примере Magento 2.

Открытый проект, где ведется разработка, и куда привлекаются комьюнити инженеры, а также где можно ознакомиться с текущим состоянием проекта и документацией, доступен по ссылке — github.com/magento-engcom/magento2/projects
Теги:
Хабы:
+3
Комментарии 0
Комментарии Комментировать

Публикации

Истории

Работа

PHP программист
149 вакансий

Ближайшие события

PG Bootcamp 2024
Дата 16 апреля
Время 09:30 – 21:00
Место
Минск Онлайн
EvaConf 2024
Дата 16 апреля
Время 11:00 – 16:00
Место
Москва Онлайн
Weekend Offer в AliExpress
Дата 20 – 21 апреля
Время 10:00 – 20:00
Место
Онлайн