It is not so much that it is not possible, but you’d have to create that yourself.
From the framework perspective we see a lot of benefit to actually tracking where an Event Processor is in handling events.
Additionally, the benefits you note might hold for small apps, but definitely do not hold when you start going large scale, or distributed.
So, regarding your two benefits:
- If you want to return a view upon the CommandGateway.sendAndWait() call, I have a different approach you might look at. This leverages the Subscription Query from the QueryGateway. When a command comes in, you’d first subscribe to the results of the view which will eventually be created. Then, you publish the command, and after a given time your Subscription Query will get the update automatically. This short sample project from my colleague Frans shows how to tackle this.
- Although this might seem nice, this couples your command and query side together. Typically, the Command side shouldn’t be influenced by any failures of the Query side, as CQRS, the segregation of the command and query side entails. It might be easier to think of the command as a fire-and-forget action. The command expresses the desire to perform some action, and if that decision was made, that’s when you’re done in that (mental) thread of execution. The Query side reacts on what has happened as a separate unit. Additionally, if you’d be using a TrackingEventProcessor and you’d have an exception, a fix in your code and then a replay potentially could solve the issue at hand.
So, to answer your last question, it is not not possible, it is just not designed that way.
Hope this helps you out Marco.
Feel free to post more questions on this forum!