Внедрение IOrderSender в объект домена

Я сталкивался с этим раньше, вот что я сделал:

Разделить локальную транзакцию удаленным вызовом процедуры.

Думаю, ничего страшного, если отправка заказа не удалась. В этом случае либо заказ размещен, но не установлен на «отправлено», либо заказ откатывается. Бизнес-оператор может вмешаться, если заказ не отправлен, или клиент позвонит, если заказ не размещен.

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

Поэтому мы решили использовать обмен сообщениями.
1) PlaceOrderService отвечает за хранение заказа и отправляет сообщение.
2) Потребитель сообщения отправляет заказ поставщику и отправляет сообщение, содержащее уведомление поставщика.
3) Другой потребитель сообщения уведомления обновляет состояние заказа.

Каждый шаг изменяет только один агрегат или просто вызывает удаленный.

Надеюсь это поможет.

Обновить

1. Как бы вы реализовали здесь часть обмена сообщениями?

Я использую решение, упомянутое в dddsample Эрика Эванса, ApplicationEvents. Это просто простой интерфейс и реализация jms, что-то вроде

    public void placeOrder(...) {// method in application service
        ....//order making
        orderRepository.store(order);
        applicationEvents.orderWasPlaced(order);//injected applicationEvents 
        //better move this step out of transaction boundary if not using 2pc commit
        //make the method returnning order and use decorator to send the message 
        //    placeOrder(...) {
        //        Order order = target.placeOrder(...);//transaction end here
        //        applicationEvents.orderWasPlaced(order);
        //        return order;
        //    }
    }

    public class JmsApplicationEvents implements ApplicationEvents {
        public void orderWasPlaced(Order order) {
             //sends the message using messaging api of your platform
        }
    }

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

хм... Я никогда не создавал торговое приложение на основе электронной почты, но вот мои предложения:

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

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

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

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