The latter type of events can be used as “integration events” because its related data was persisted for sure, therefore, you could use any implementation of a EventBus.Publish() and publish asynchronously that event to any subscriber whether the subscriber is in-memory or is remote and out-of-process and you are communicating through a real messaging system like a Service Bus or any queue based system that supports a Pubs/Subs model. In the latter case, it really has happened in the past, from an application and persistence point of view.
When discussing about “Domain Events” there’s certain lack of clarity because sometimes you can be talking about Domain Events that happened but within the same transaction scope of the operation that is still in memory objects (so I fact, it still didn’t happen from a persistence point of view) or, on the other hand, you could be talking about events that were already committed in your persistence storage and must be published because of state propagation and consistency between multiple microservices, bounded-contexts or external systems. So, feel free to discuss about it with comments at the end of this post. I might evolve this post depending on feedback and some implementations we’ll be doing in the short/medium term. Integration Events patterns already published by the community.
This blog post is about comparing several approaches of Domain Events vs.
0 kommentar(er)
