aplicativo ASP.net MVC3 / NHibernate do @My tem um requisito para disparar e manipular uma variedade de eventos relacionados aos meus objetos de domínio. Por exemplo, umOrder objeto pode ter eventos comoOrderStatusChanged ouNoteCreatedForOrder. Na maioria dos casos, esses eventos resultam no envio de um email, por isso não posso deixá-los no aplicativo MVC.

Eu li @ de Udi DahDomain Events e dezenas de outras idéias sobre como fazer esse tipo de coisa, e decidi usar um host baseado no NServiceBus que lida com mensagens de eventos. Fiz alguns testes de prova de conceito e isso parece funcionar be

Minha pergunta éque camada de aplicação deve realmente aumentar os eventos. Não quero acionar os eventos até que o objeto em questão tenha sido mantido com êxito (não é possível enviar um email informando que uma nota foi criada se a persistência falhar

Outra preocupação é que, em alguns casos, um evento esteja vinculado a um objeto que esteja abaixo de uma raiz agregada. No exemplo acima, umNote é salvo adicionando-o aoOrder.Notes coleta e salvando o pedido. Isso representa um problema, pois torna difícil avaliar quais eventos devem ser disparados quando umOrder é salvo. Gostaria de evitar a necessidade de puxar uma cópia atual do objeto e procurar diferenças antes de salvar a cópia atualizad

É apropriado que a interface do usuário crie esses eventos? Ele sabe quais eventos ocorreram e pode acioná-los somente após a camada de serviço salvar o objeto com êxito. Algo parece errado em ter um controlador disparando eventos de domínio.

O repositório deve disparar eventos após persistir com êxito?

Devo separar os eventos por completo, fazer com que o repositório armazene umEvent objeto que é captado por um serviço de pesquisa eentã se transformou em um evento para o NServiceBus (ou tratado diretamente do serviço de pesquisas)?

Existe uma maneira melhor de fazer isso? Talvez os meus objetos de domínio enfileirem eventos que são disparados pela camada de serviço somente após a persistência do objeto?

Atualizar Eu tenho uma camada de serviço, mas parece complicado e excessivo passar por um processo de comparação para determinar quais eventos devem ser disparados quando uma raiz agregada é salva. Como alguns desses eventos são granulares (por exemplo, "status do pedido alterado"), acho que precisaria recuperar uma cópia do banco de dados do objeto, comparar as propriedades para criar eventos, salvar o novo objeto e enviar os eventos para o NServiceBus quando a operação de salvaguarda foi concluída com êxito.

Atualiza

O que acabei fazendo depois da resposta que publiquei abaixo abaixo), foi incorporar em minhas entidades de domínio umEventQueue propriedade que eraList<IDomainEvent>. Em seguida, adicionei eventos à medida que as alterações no domínio o mereciam, o que me permitiu manter a lógica dentro do domínio, o que acredito ser apropriado, pois estou disparando eventos com base no que está acontecendo dentro de uma entidad

Então, quando eu persisto o objeto na minha camada de serviço, eu processo essa fila e realmente envio os eventos para o barramento de serviço. Inicialmente, eu estava pensando em usar um banco de dados legado que usava PKs de identidade, então tive que pós-processar esses eventos para preencher o ID da entidade, mas finalmente decidi mudar para umGuid.Comb PK, o que me permite pular essa etap