Подтверждение с помощью других моделей

Question

Каковы варианты проверки того, что использует другая модель?

Корзина Пример:

При добавлении корзины товар в корзину, должна быть проверка, если товар не продан еще.

Answer 1

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

В ответ на вопрос, как правило, это зависит от того, что бизнес стоимость процесса. Например, в вашем примере, какова стоимость для заказа заказа предмета, который продан? Наверное, очень мало - по электронной почте, говорящей, что товар отсутствует на складе, с оценкой того, сколько времени это займет.

В этом типе сценария вы можете использовать согласованную модель чтения по данным, где вы запрашиваете модель/кеш для чтения для уровней запасов, но согласитесь, что некоторые заказы могут пройти через вещи, которые отсутствуют на складе ,

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

Answer 2

Каковы варианты проверки события, которое использует другую модель?

A domain event является важным событием с точки зрения бизнеса. Это то, что происходит в прошлом, поэтому его нельзя изменить. В OO он обычно представлен как Value Object, то есть непреложный объект, где интересной частью являются их атрибуты.

Обычно эти Domain Events являются результатом операции в Aggregate Root (DDD-жаргон). Клиентом Aggregate Root является Application Service (aka use case). Application Service получает объект Command и базу на нем, выполняет операцию в Aggregate Root.

Валидация может состоять в примитивной проверке, проверке объекта и/или составлении объекта. Тогда объект, ответственный за выполнение этой проверки, должен быть сам Aggregate Root и/или некоторые объекты с определенной целью в валидации.

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

После вашего примера объекты woulb быть:

• Команда: AddItemToShoppingCartCommand. Сохраняет информацию о добавляемом элементе и, например, идентификатор корзины покупок.
• Заявка на обслуживание: AddItemToShoppingCartService.
• Совокупный корень: ShoppingCartInventory. Я использовал намеренно Inventory в имени, чтобы быть явным, что этот Aggregate Root удовлетворяет инварианту «... если элемент еще не распродан."

Примечание: На мой взгляд, инвариант, который проверяет инвентарь в Aggregate Root, делает Совокупные слишком большой Мой совет расслабить этот инвариант и принять окончательное консистенцию, если это.„Распроданы“, это обычно не происходит.