incoherent CQRS ramblings

ramblings.txt

At $work, we've decided to introduce a message bus to unify the way our
different applications talk to each other. And since a message bus carries
messages,  the communication is pretty much in event + exception style.

From there it's only a small step to consider how to structure those messages,
and a separation into commands, queries and responses seems quite naturally.

And from the terms alone, "command, query, response" - hey, should we do CQRS?
So far the answer is "no", due to two main concerns:

1) The message bus is inherently asynchronous in nature. A pretty common use
case (for example in web applications) is: send a command that updates some
things (for example new shipment address), and then display the result (for
example the shipment address, and the new shipment price based on the
address). If we do pure CQRS, the "update shipment address" command won't send
any confirmation. How do I know when I can send the query that's guarantueed
to happen after the command has taken effect? (The message bus doesn't
always preserve the order of messages)

2) Performance: it seems pretty wasteful to take two round trips through the
message bus in the scenario above; if the command answered with the updated
data right away, it would be only one round trip.

So in summary, it seems that mixing CQRS with asynchronous event delivery is
either a bad idea, or needs very careful planning to get consistency and
sequential ordering right.