Как обрабатывать сбои в возможной согласованности между агрегатами в DDD?

Допустим, я реализую проект, управляемый предметной областью, с использованием C# и Entity Framework.

Мой код структурирован таким образом, что каждый агрегат имеет собственный dbcontext в EF, чтобы соблюдать принцип транзакционных границ вокруг моих агрегатов.

Агрегат 1, InventoryAggregate и агрегат 2, OrderAggregate, обновляются некоторым бизнес-процессом AddItemToOrder.

После того, как OrderAggregate добавляет элемент, он запускает событие предметной области ItemAddedToOrder, которое прослушивается InventoryAggregate, который затем выполняет некоторый бизнес-процесс SubtractQuantityFromInventory.

InventoryAggregate не может вычесть инвентарь и запускает доменное событие NotEnoughInventory, прослушиваемое OrderAggregate.

Затем OrderAggregate пытается удалить элемент из заказа, но терпит неудачу.

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

Как с этим справиться?


c# entity-framework domain-driven-design eventual-consistency
person drizzie    schedule 19.03.2016    source источник

Ответы (1)


arrow_upward
1
arrow_downward

То, что вы описываете, является диспетчером процессов. Вероятно, вам нужен какой-то OrderProcess или QuoteProcess AR, который обрабатывает состояние вашего процесса. Если вам нужно сначала выполнить некоторую проверку бизнеса, например, проверить инвентарь, вам нужен менеджер процессов, чтобы вы создавали фактический Order только после того, как установили, что его действительно можно отправить.

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

person Eben Roux    schedule 19.03.2016
comment
Возможно, я пытаюсь решить нереальную проблему, но я думаю, что этот обмен происходит после того, как проверка прошла. Возможно, OrderAggregate не работает из-за сбоя сети или проблемы с записью на диск. При согласованности транзакций вся транзакция будет откатываться, но при окончательной согласованности между агрегатами мы должны предположить, что следующий агрегат станет согласованным. - person drizzie; 19.03.2016
comment
Ваша проблема, вероятно, не так уж и нереальна. Хотя к этому можно было подойти по-разному. Например, если вы уверены, что конкретное сообщение, отправленное из одного AR в другое, на 100 % правильное, и единственная причина, по которой оно может не сработать, носит технический характер, и у вас есть гарантированный механизм доставки сообщения, то вы можете безопасно < b>предположим, что ваш другой агрегат в конечном итоге станет согласованным. Однако если обработка сообщения может завершиться неудачей из-за бизнес-условий, и вам нужно как-то это компенсировать, тогда вам либо понадобится процесс, либо вы загрязните другие AR семантикой процесса. - person Eben Roux; 20.03.2016