To sum up, all elements that were introduced in this section, we can draw a conceptual picture like this:

The transcription for this picture would be:

The user, using information from the system, represented as the read model, and information from the outside world, feelings and own thoughts of the user; send operation requests to the system, known as commands, which might result in the system state change and that produces domain events. Domain events can trigger policies, which might issue new commands, based on the information received in those events and the system state. External systems could also produce domain events. The system state change results in reading models to be updated as well so the user can receive new information from the system and the cycle repeats.

This diagram can describe the majority of systems out there, and you could imagine that it is applicable not only to software systems. The picture also maps very nicely with CRQS and this, I believe, makes CQRS pattern so useful. Some might argue that CQRS adds accidental complexity to the system due to implementation efforts. However, when done correctly, it adds more clarity to the model(s) because it directly implements the separation of concerns (SoC) principle ("On the role of scientific thought" by Edsger W. Dijkstra, 1974 paper) and in general makes the system easier to build and maintain.