Дело в том, что я не могу предположить, что события, которые мне понадобятся, будут соответствовать исключительно «деловым действиям». В соответствии с предложенным вами решением я не смог бы вызвать событие, кроме как через метод уровня обслуживания. Это не идеально для случаев, когда одна логическая транзакция запускает несколько событий, так как для этого требуется постоянная операция для каждого бизнес-действия, связанного с событием (напомним, что мой первоначальный вопрос был связан с событиями, зависящими от персистентности).
м приложении ASP.NET MVC3 / NHibernate требуется отключать и обрабатывать различные события, связанные с объектами моего домена. Например,Order объект может иметь такие события, какOrderStatusChanged или жеNoteCreatedForOrder, В большинстве случаев эти события приводят к отправке электронной почты, поэтому я не могу просто оставить их в приложении MVC.
Я прочитал Уди ДаанаСобытия домена и десятки других мыслей о том, как делать такие вещи, и я решил использовать хост на основе NServiceBus, который обрабатывает сообщения о событиях. Я сделал несколько проверок концепции, и это, кажется, работает хорошо.
Мой вопроскакой прикладной уровень должен на самом деле вызывать события, Я не хочу запускать события до тех пор, пока рассматриваемый объект не будет успешно сохранен (не могу отправить электронное письмо о том, что заметка была создана в случае сбоя сохранения).
Другая проблема заключается в том, что в некоторых случаях событие связано с объектом, который находится под совокупным корнем. В приведенном выше примереNote сохраняется путем добавления его вOrder.Notes Сбор и сохранение заказа. Это создает проблему, заключающуюся в том, что трудно оценить, какие события должны запускаться, когдаOrder сохраняется Я бы хотел избежать необходимости извлекать текущую копию объекта и искать различия перед сохранением обновленной копии.
Уместно ли для пользовательского интерфейса поднять эти события? Он знает, какие события произошли, и может инициировать их только после того, как сервисный уровень успешно сохранит объект. Что-то не так с контроллером, запускающим события домена.
Должно ли хранилище запускать события после успешного сохранения?
Должен ли я полностью отделить события, чтобы хранилище хранилиEvent объект, который затем забирается службой опроса итогда превращается в событие для NServiceBus (или обрабатывается непосредственно из службы опросов)?
Есть лучший способ сделать это? Может быть, объекты моего домена помещают в очередь события, которые запускаются сервисным уровнем только после того, как объект сохраняется?
Обновить: У меня есть сервисный уровень, но он кажется громоздким и чрезмерным, чтобы он проходил через процесс сравнения, чтобы определить, какие события должны запускаться при сохранении заданного совокупного корня. Поскольку некоторые из этих событий являются гранулированными (например, «статус заказа изменен»), я думаю, что мне придется извлечь копию объекта БД, сравнить свойства, чтобы создать события, сохранить новый объект, а затем отправить события в NServiceBus, когда операция сохранения успешно завершена.
ОбновитьТо, что я в итоге сделал, после ответа, который я разместил ниже (намного ниже), должен был встроить в мой доменEventQueue собственность, которая былаList<IDomainEvent>, Затем я добавил события, поскольку изменения в домене заслуживают этого, что позволило мне сохранить логику в домене, что я считаю уместным, поскольку я запускаю события, основываясь на том, что происходит внутри сущности.
Затем, когда я сохраняю объект на своем сервисном уровне, я обрабатываю эту очередь и фактически отправляю события на сервисную шину. Первоначально я планировал использовать устаревшую базу данных, в которой использовались идентифицирующие PK, поэтому мне пришлось пост-обрабатывать эти события, чтобы заполнить идентификатор объекта, но в конечном итоге я решил переключиться наGuid.Comb ПК, который позволяет мне пропустить этот шаг.