I just want to clarify this case (whether it is prohibited conceptually or even enforced by Axon).
Quote 1:
“Aggregates will only react on events generated by that same aggregate instance.”
https://groups.google.com/d/msg/axonframework/vPxHsNsC4cg/PNfYmH5jEAAJ
Quote 2:
“An Aggregate’s event handlers are only invoked when it is loaded from the event store.”
https://groups.google.com/d/msg/axonframework/Xp_6SygKOxk/KJuNIL0RDuAJ
Quote 3:
“About the rule not to send events from an event handler: for event handlers inside an aggregate that is a very strict rule. Failure to comply will inevitable result in exceptions. The reason is that these event handlers are also invoked when the aggregate is reconstructed from past events. Applying a new event in one of those would cause the event to be re-applied each time the aggregate is loaded…”
https://groups.google.com/forum/#!msg/axonframework/4pcGCvRNTSw/mJA-AAODudcJ
It is very clear when single aggregate instance is in question:
Basically, it means that event handlers of an aggregate are “read-only” in respect to the aggregate instance.
In other words, they never introduce new events in the event log for this aggregate instance.
Question 1: What about events which are never applied on the same aggregate instance and handled by non-aggregate event handler (in some view model)?
For example:
- Event instance E1 is applied to aggregate instance A1. This results in event instance E2 (of the same or any other type) being sent.
- By careful design it is guaranteed that event instance E2 is never handled by this same aggregate A1.
Note also that specifically because of the constraint in the quotes above, event instance E1 cannot be sent to another aggregate instance (“Aggregates will only react on events generated by that same aggregate instance”). Therefore, in order to avoid useless fate for such event instance E2, the only possible option for it is to be handled by non-aggregate event handler.
Question 2: I may guess there could be another conceptual constraint (for reasons yet unknown to me) that an instance of event cannot “hang in the air” without belonging to an event log of one of the aggregate instances. Is this true?
Actually, I can think of one reason to prohibit events “hanging in the air”. For example:
- Imagine there is a view model V1 which was constructed based on realtime events since day 1.
- Now (after long time in production), we decided to add another view model V2 which is to be constructed based on recorded events from the event store.
V2 won’t see (necessary) events compared to what V2 has seen so far. In short, V2 view model may miss some important data.
Question 3: Almost the same as Question 2 but specifically for event store. If events can “hang in the air”, does event store actually somehow capture events which are not associated with any of the aggregates?
Hi Alexey,
All events in the EventStore belong to some aggregate.
As explained in quote 3, you cannot send additional events from within an event handler.
So for question 1, the example is wrong: this event E2 cannot happen.
However, events (contrary to commands) can be handled by several event handlers. e.g. E1 can be processed by an event handler defined in the aggregate type (to alter state of aggregate instance) and also be processed by a 2nd event handler (defined outside aggregate type) to update some view model.
Cheers,
Benoît
Hi Alexey and Benoît,
Hope I’m not going to make things more confusing than necessary but starting with Axon 2.3 it is in fact possible to apply new events from within aggregate event handlers. These events will also end up in the event log for that aggregate.
See eg http://www.axonframework.org/news/axon-2-3-released/
As explained there, events applied while an aggregate is being loaded are simply ignored. This new functionality was added a year after quote 3 from Allard.
Furthermore, publishing events from non-aggregate event handlers has always been possible. Not sure, but I was under the impression that that was what question 1 was about but let me know if you meant something else.
Regarding question 2 and 3. You’re right that events published from outside aggregates currently are not saved to the event store. However, starting with Axon 3 they will be. This means that these so-called application events will also be seen during event replays, preventing the issue described in question 2.
Best,
Rene
Hi Rene and Benoit,
Both question 2 and question 3 are actually very clear - thanks for confirmation!
And feature of Axon 3 to store “application events” is good to note for future use.
Now we only focus on Question 1 (rephrased for clarity): “Can one aggregate event handler (A1) publish events “outside its event log” (like E2) to be processed by non-aggregate event handlers?”.
Let’s summarise what we have:
-
Alexey: “Event instance E1 is applied to aggregate instance A1. This results in event instance E2… event instance E2 is never handled by this same aggregate A1”
-
Benoît: “So for question 1, the example is wrong: this event E2 cannot happen.”
-
Rene: “Furthermore, publishing events from non-aggregate event handlers has always been possible. Not sure, but I was under the impression that that was what question 1 was about but let me know if you meant something else.”
I discovered one possibility from Rene’s answer: we can publish events from non-aggregate event handlers.
I’m glad to know it now by the way.
What I’m still not clear about is why aggregate event handlers can not do this trick as well - the event destination is non-aggregate event handler.
Feel the difference:
Non-aggregate event handlers are able to publish events “outside any event log” (which are lost events in Axon 2.x).
But aggregate event handlers are unable to publish events “outside their event log” (which technically should behave equally and become lost events in Axon 2.x as well).
Benoît’s also confirms this as hard truth. What I want to know is whether it is:
(A) implementation limitation,
(B) purposeful restriction for foolproof Axon use,
(C) unknown possibility which exists but nobody needs in practice.
Any guess which case is it?
Regards,
Alexey
An aggregate can publish events that it doesn’t listen to itself. In that case the events still end up in the log though. That’s usually not a big deal: they will just be ignored by the aggregate when it is event sourced.
So right now, it’s not possible to prevent such events from being added to the event log of that aggregate. That’s more a technical limitation than anything else I guess. Also, it’s not directly clear what problem this pattern would solve so I bet there has not been a lot of demand for such a feature.
Regards,
Rene
Hi Rene,
> “An aggregate can publish events that it doesn’t listen to itself. In that case the events still end up in the log though. That’s usually not a big deal: they will just be ignored by the aggregate when it is event sourced.”
This possibility is actually what I was thinking about.
Just a comment:
In fact, looking at “application events” of Axon 3 mentioned before, these “events ignorable by aggregates” could also become implemented via “application events” as well.
That way they both conceptually and by implementation do not belong to publishing aggregate event log.
I got clarified more than I initially intended.
Thank you!
Regards,
Alexey