0

I've made some small research about Domain Events, and have found few different solutions

  • Udi Dahan solution, which handle events immediately
  • Deferred domain events, which fire off in infrastructure mostly
  • Domain Events which return result

Questions:

  • Which one is a pure Domain Events ?
  • Is it possible to have them all in the same project ?
  • In that case how should I name and distinguish them ?
  • Where to register EventHandler ? Someone mentioned that Application Service is appropriated place, but here I've seen that it was registered right into the Domain Model, and handled there, as well, and not in separate Event handler class.

One more extra question.

For example: When order is created and paid it has to get status "OrderPaid".

Because purchasing and ordering are two different contexts, right after Order was created we need to rise a Domain Event, which should be handled by Event Handler in Purchasing bounded context, but in result of Event Handling, there should be raised one more Domain Event - OrderPaid, which might be handled by Order context again. With monolith application it seems that one solution might be: pass Order object into Event Handlers to achieve expected behavior. Is there any other ways how to solve it, in such architecture style ?

4

1 回答 1

1

发明领域事件是为了提供更封装的领域模型。没有纯粹的实现，只有不同的实现和不同的权衡。您可以在同一个项目中举办活动，并且在您引用的文章中对活动的命名提供了大量指导。

如果您希望处理在不同有界上下文之间最终保持一致的长时间运行的进程，我可能会考虑使用像NServiceBus或MassTransit这样的共享消息总线。

于 2016-04-01T08:23:05.833 回答