I just want to clarify this case (whether it is prohibited conceptually or even enforced by Axon).
“Aggregates will only react on events generated by that same aggregate instance.”
“An Aggregate’s event handlers are only invoked when it is loaded from the event store.”
“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…”
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)?
- 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?