In our application, we intentionally made a distinction between domain
and application events, the former relating to events that update the
state of aggregates, the latter containing calculated totals that need
to be relayed to the query side.
We stumbled upon some nasty timing issues, caused by the application
events always being put on the event bus first before the domain
events are being published. This implies that the totals relate to
data that are not yet present on the query side.
Looking at the implementation of the Axon framework, we concluded that
it is not possible to maintain the order between application and
domain events, the former always being put on the event bus first.
Is there any reason for this behavior? As far as we can tell, this
behavior can be quite misleading, as application events that are
seemingly put on the bus last in the code (in the aggregate), are in
fact put on the bus first, since the domain events are buffered in the
aggregate and are put on the bus last by the repository.
If there is no such reason, perhaps it would be useful to consider to
implement an apply() method accepting application events as well?
here is the short answer: your use case sounds reasonable, but I just hasn’t been implemented like that, yet. I’ll get started on that.
Reading thorugh the way you use your events, it does sound to me that the application event you are referring to might actually be a domain event. It sounds like a report of a certain state being reached in an aggregate. Application events are typically used to indicate something has happened outside the domain (such as elapsed time or a query being done without proper authorizations).
Anyway, that discussion is separate from the one about event publication order.
here is the short answer: your use case sounds reasonable, but I just hasn't
been implemented like that, yet. I'll get started on that.
Great to hear that, and thanks for your fast response!
Reading thorugh the way you use your events, it does sound to me that the
application event you are referring to might actually be a domain event. It
sounds like a report of a certain state being reached in an aggregate.
Like you said, this is a separate discussion, but we have are dealing
with
an account containing funds, and every day new fund rates lead to new
calculations of fund totals, statistics and what not. These new fund
rates
lead to a multiple new events per account, leading to Gigs of data in
the
event store, all storing event data that are not needed to "resurrect"
aggregate
roots, hence we considered these totals/statistics not really part of
the
domain, and refactored them to application events. The size of the
event store
shrunk enormously, but apart from the timing issues everything else
remained
fully operational. This strengthened our conviction we made the right
decision.
On the other hand some good news: 2 weeks from now our second CQRS/
Axon
based application is going live at ABN-AMRO!