Sending the response message of API after command success or failed

I using the constructor of aggregate with command handler annotation , to create create the new instance of the aggregate. Now after the creation , the api have to send the response message to UI (which shown to user). How I can achive this ? and what is the best way to to this ?

I was learned about the following pattern ,, please suggest any good way or example to implement this .

In simple cases your API endpoint handler can construct a command and use sendAndWait() to send the command via the command gateway.
sendAndWait will throw an exception if the the command was not dispatched successfully.
The issue is that your projections will not necessarily be up to date on return from sendAndWait() – so you can’t “read your writes”.

There is a discussion on the “read your writes” issue here
It has some sample code.

In our project we have built on the understanding gained from the sample code to create an implementation pattern of correlated commands and events.
Our projections publish on the query bus to allow senders of correlated commands to know when their write is readable.
It’s working well and is a surprisingly small amount of code.
From the link above it sounds like Axon will provide something like this at some point…

Hi Aswani, Steven,

Aswani, what kind of response are you looking for to be returned as part of a command execution?
The framework does not impose any restriction on returned values from Command Handlers at the moment.
However, from a usage perspective we suggest that you only return a void (in case of success or ignore), an exception (for failure) and Identifiers of Aggregates/Entities which were constructed as a result of handling the command.
A command handling constructor will actually by default provide you with the Aggregate Identifier, instead of the Aggregate instance.

Thus, if the response you’d want to give to the UI is an identifier to be able to retrieve a query model, this should already be doable.

What Steven points out should also proof valuable, given the scenario you need to reply with an actual Query Model, spoofing a synchronize operation on the back-end.
I think his suggestion would be sufficient given you’re interested in the entire Query Model.

Lastly, as pointed out, we’re indeed looking into adding the some indication in the Command Response pointing to the sequence of the last event published as a reaction to the given command.
With this, you should in turn be able to query your model adding this sequence number to the query you dispatch as an expectation your Query Model should comply too.
As shared, this is however not yet implemented.

That’s my 2 cents to the situation.