DDD «Заказы и инвентаризация» - где обрабатывается распределение / резервирование?

Question

Я пытаюсь реорганизовать устаревшую систему обработки заказов и склада в более чистую сервисно-ориентированную архитектуру, управляемую событиями Однако мне трудно решить, какая служба должна отвечать за резервирование / распределение акций.

Краткий обзор текущей системы

1. Заказы на продажу размещаются у нас через стороннюю систему, но у нас не обязательно есть все строки заказа на складе.

   • Если позиция заказа есть в наличии, тогда мы сразу же распределяем / резервируем запас для этого заказа.
   • Однако, если у нас нет достаточного запаса, мы закупаем запас у наших поставщиков через систему закупок.

2. Когда товар поступает от поставщика, система проверит все открытые заказы на продажу для этого товара и зарезервирует / выделит для него доступный запас с приоритетом по дате заказа на продажу. ***

Я уже определил две службы, которые, по моему мнению, должны быть разработаны

• Продажи - Ответственный за получение заказа на продажу и вставку в базу данных. Имеет доменные объекты, такие как Order, OrderLine и т. Д.

• Инвентаризация - отвечает за отслеживание того, сколько запасов имеется на нашем складе. Имеет доменные объекты, такие как StockItem.

Однако, поскольку распределение / резервирование запасов касается как запасов, так и продаж, я не уверен, куда следует поместить поведение, описанное в пункте 2 выше.

Я приветствую любую помощь или мысли по этому поводу.

Answer 1

Я думаю, что у вас есть 2 BC (ограниченные контексты): инвентарь и продажи. Для интеграции между ними я бы, вероятно, пошел на подход доменных событий.

Когда новый товар поступает на склад, BC запаса увеличивает запас товара и публикует событие.

Sales BC подписывается на событие и обновляет открытые продажи, ожидающие позиции на складе.

Итак, поведение «точки 2» разделяют оба БК:

• Sales BC поиск открытых заказов, ожидающих этого товара. И затем он просит Inventory BC получить необходимое ему количество предметов (этот запрос является синхронным) и закрыть заказ.

• Инвентаризация BC получает запрос и уменьшает запас для позиции.

Answer 2

Вы упомянули SOA и NServiceBus, поэтому моя первоначальная мысль состояла в том, что вы посещали Udi Dahan его тренинг ADSD? Я предполагаю, что у вас есть. На этом я постараюсь ответить на ваш вопрос.

Пока у меня мало информации. Но, учитывая то, что у нас есть, я решил, что нам нужны эти свойства, чтобы хранить все, что вы упомянули.

• ProductId, по одному на каждый доступный продукт
• InventoryTotal, прикрепленный к ProductId. Это число идет вверх и вниз
• OrderId, для создания заказа
• OrderDate, чтобы убедиться, что мы можем найти заказ, который должен получить входящий запас первым.

Если у вас есть OrderId, вы можете прикрепить один или несколько ProductId, чтобы создать фактический заказ. Различные способы хранения этого технически. Может быть, в реляционной базе данных с таблицами Order и OrderLine, или, возможно, в DocumentDb, где все хранится в одном документе. Это совершенно не имеет значения в данный момент.

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

Если вы хотите обсудить это, свяжитесь с нами по адресу support@particular.net, укажите мое имя, и мы сможем продолжить беседу.

Answer 3

Однако, поскольку распределение / резервирование запасов касается как запасов, так и продаж, я не уверен, куда следует поместить поведение, описанное в пункте 2 выше.

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

Таким образом, система инвентаризации кэширует свою собственную копию данных, необходимых для выполнения заказа (что позволяет ей работать автономно). Он должен быть в состоянии добиться прогресса, как только ему сообщат, что поставщики предоставили новые запасы, даже если система продаж оказывается недоступной для технического обслуживания.