The conceptual clarity of CQRS

(written by lawrence krubner, however indented passages are often quotes). You can contact lawrence at: lawrence@krubner.com

Interesting:

I found the cognitive load to be less than with other service based architectures I have worked on. I could jump into any area of the code base and because of the naming conventions for commands and events I could see what was going on – this has never been my experience with a service oriented architecture.

The main change in developer thinking that is necessary is that you don’t record state you record state transitions. Once that is internalised development is easy, a new feature requires new commands and handlers, new events, new queries and an updates to aggregates.

I had absolutely no problem with cross cutting concerns – security for example was handled in command handlers where needed. Other system components of our system that didn’t use CQRS – for example reporting, general ledger, third party integrations – received data from the event stream and injected commands back into the system. So in no way was our organisation infected by CQRS / ES.

Source