Hi Robert,
Nice lay out of your scenario/situation and thanks for sharing it!
I think such a breakdown is an interesting read for any user of the framework or for those who are creating a DDD/CQRS/ES microservices application.
For you question though, you have hit a common pain point for several I’d say.
By default I’d state that the front-end should embrace the fact that it is dealing with commands and queries.
Which means, that dispatching a command by definition does not provide you the query result.
A command should be regarded as a fire and forget operation, resulting solely in an OK or NOK (with an optional identifier attached to it).
If the front-end then needs information, then it should perform a query to retrieve that data, separately from the command dispatching.
The Subscription Query, like you’ve pointed out, makes it cleaner from the usage perspective, as this more so embraces the asynchronous nature of your application.
However, this is obviously the ideal world, and sometimes you are required to have synchronous operations.
From a purist stand point, I’d suggest to push these back as much as possible, but if you have to, I’d indeed follow your suggested pattern.
Thus, you’d perform a subscription query with the knowledge that data will be updated as you will follow it up immediately with a command thereafter.
This repository shows this idea off quite nicely actually.
That’s my two cents on this.
Cheers,
Steven
PS. At AxonIQ we’re aware of another Crypto Currency Management application. Maybe we can provide some guidance on this part, if you’re interested that is.