DDD: реализация доменных событий в монолитном приложении

Question

Я провел небольшое исследование о предметных событиях и нашел несколько разных решений.

• Решение Udi Dahan, которое обрабатывает события немедленно
• События с отложенным доменом, которые в большинстве случаев запускаются в инфраструктуре
• События домена, которые возвращают результат

Вопросы:

• Какой из них является чисто доменными событиями?
• Возможно ли иметь их всех в одном проекте?
• В таком случае, как мне их назвать и отличить?
• Где зарегистрировать EventHandler? Кто-то упомянул, что Служба приложений - это подходящее место, но здесь я видел, что она была зарегистрирована прямо в Модели Домена и там же обрабатывается, а не в отдельном классе обработчика событий.

Еще один дополнительный вопрос.

Например: когда заказ создан и оплачен, он должен получить статус "OrderPaid".

Поскольку покупка и заказ - это два разных контекста, сразу после создания Заказа нам нужно вызвать событие домена, которое должно обрабатываться обработчиком событий в ограниченном контексте покупки, но в результате обработки события должно возникнуть еще одно событие домена - OrderPaid, который может быть снова обработан контекстом Order. С монолитным приложением кажется, что может быть одно решение: передать объект Order в обработчики событий для достижения ожидаемого поведения. Есть ли другие способы, как это решить, в таком архитектурном стиле?

Answer 1

События домена были изобретены, чтобы обеспечить более инкапсулированную модель домена. Там нет чистой реализации как таковой, просто разные реализации с разными компромиссами. Вы можете разместить свои события в одном проекте, и в статьях, на которые вы ссылаетесь, содержится множество рекомендаций по наименованию событий.

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