Yes, so many buzzwords together - I admit.

The difference is replacing Commnad/Query with events. Replacing Imperative with Reactive.

Did you read the whole post or you were put off by the buzzwords?

Perhaps it's because it is Sunday but I phased out after the first couple of paragraphs. I've read it now and am still unaware of why this is fundamentally better.

Command/Query pattern is an imeplementation concern. The architectural pattern that backs it up isn't necessarily related (for example event sourcing). At that point it isn't imperative so why is this different? It just appears to be fragmenting lots of concerns into even smaller ones which are vastly more complicated to debug and manage.

The bold highlighted text of: "in a reactive actor system, each actor only knows about its own Step and what itself does and has no clue about the next steps or the rest of the system"

Isn't that the same for a message channel but without a transactional guarantee? (going back a decade or more to EIP).

No it is not the same. First of all, CQRS is applying CQS to the architecture, so it is an architectural decision. When you use commands, you know about the interface of the endpoint receiving your message. In case of an event, you do not have to know anything - and this is the whole premise of this post. In the article to come, I have explained the differences more with regard to EIP as well. A half-draft available at https://gist.github.com/aliostad/55b652e44dfe87d44444

Thanks. I'm sceptical (having been through several similar systems and ripped them out) but I will read your draft later.