you say:
"The approach chosen by the original implementer was to put a Spring DeferredResult into a static map and have the EventHandler complete the query/response rendering, but this is clearly the wrong place to do such processing as it’s a violation of SRP (amongst other things). "
However, I’m not so sure if it’s a violation of SRP. The responsibility (apparently) is to communicate state between client and server. To return correct state, the reply may need to wait for an event, and it’s fine for the component to do so.
However, it’s probably not the nicest solution.
First of all, it seems the API doesn’t seem to be compatible with eventual consistency. That’s the main issue here. But we’ll take that as a given, just for the sake of getting a solution.
The best is to return to the user based on the results of the Command Handler method. If a change is requested, and the command returns an OK, it is safe to assume the change was successful. So do a query, check if the result is as expected and otherwise apply the expected result.
If that is too complex, consider doing a query that returns the sequence number of the last event included in the model. From your command, return the sequence number of the events applied. Do queries until the sequence number is higher than the one returned. That’s when the deferred result “completes”.
These patterns are your typical sync-async solutions. They’re not beautiful, but needed when an async process is forced down a sync API.
Thanks for the considered reply.
Even if it doesn’t violate SRP (and I would argue that it is the controller’s responsibility to coordinate the response rendering by the view) it certainly looked unusual and took me a while to realise what was going on.
Yes, I would agree that this API is particularly nasty from an eventual consistence point of view. My guess is that the API spec was designed by frontenders for their convenience (there is a sister project that compares front-end projects). However it would contend that it is of interest because it is exactly the kind of real-world scenario that tends to come up.
A couple of supplementary questions, if I may:
In my working solution, since no persistence is required, I just provided a minimal Repository implementation rather than use the framework ones. Would I need to replace that with a framework Repository implementation?
Also, using such a repository (while working for the application) does not work with the Aggregate (Given-When-Then) Framework tests. Again, is it best to go with a standard Repository implementation?
Also, would either approach rely on Aggregate Versioning to tell if the aggregate has been updated?
the Axon Repository implementations are only required for the command side of the application (the command model, which contains your Aggregates). You can pick or create any implementation that suits your needs. Strictly speaking, you don’t even have to use the Repository by Axon at all. In that case, you will have a Command Handler bean (regular singleton that has @CommandHandler annotated methods) that does whatever it needs to do when a command comes in.
I am not sure what you mean with “Aggregate Versioning” in “Also, would either approach rely on Aggregate Versioning to tell if the aggregate has been updated?”. If you refer to the Repository.load(identifier, version) method, then using the Axon Repositories is particularly helpful, as everything is implemented for you. This mechanism is used to detect concurrent modifications that may have occurred due to decisions based on stale data (which is always the case, not just because of eventual consistency).
The Given-When-Tests are useful, but only when the aggregate was designed to be event sourced. For other aggregates, the testing is very similar to any other test, so there is not special fixtures needed.