There similar but yet different concepts that confuses some developers when they see these definitions and trying to understand what is the relation between the terms. Let’s try to figure it out.
CQS stands for Command-query separation. Initially designed by Bertrand Meyer as a part of his work on Eiffel programming language. The core idea behind this concept is that
Every method should either be a command that performs an action, or a query that returns data to the caller, but not both.
Application of this principle makes software design cleaner and code easier to read and understand it intent. Usually, you apply it on source code level by creating clear interface definitions, followed by implementation which should adhere to command-query separation rules. For in-depth overview of CQS in action and it affect on design see my article CQS and its impact on design.
CQRS stands for Command Query Responsibility Segregation. It is architectural pattern. It is related to CQS in the way that the main idea of that pattern is based on command-query separation. But unlike former CQRS applied not on a code level but on application level. Originally this pattern was described by Greg Young in his CQRS Documents.
In a nutshell it says that your write model is not the same as your read model because of different representation logic behind it: for your web pages you could have views specifically adapted for representation logic of the UI elements on it. And write model contains all data in format which best fits type of the data. If you familiar with SQL, read model is something similar to SQL Views (which is just projection of data in convenient form).
This gives you not only flexibility in separation of representational logic, but also in choosing underlying storage technologies. Write model storage could be in good old SQL and read model could be in MongoDB or any other NoSQL DBMS. In essence it is SRP (single responsibility principle) at application level.
Event sourcing is technique to store data as a series of events where these events acts as source of truth for data. The key idea here is that each change to the data is event which is stored with metadata like timestamp and relation to aggregate root (often CQRS applied with DDD where aggregate root is domain object which encapsulates access to the child objects).
In that way you have history of all changes to your data over lifetime of application. Next key aspect of such systems is that in order to get current state of domain object all events for its aggregate root should be replayed from the beginning (there some tricks like snapshots which solve performance issues with that approach when you have huge amount of data). In the same manner, current state of a whole application is a sum of all events for all aggregate roots. This is very different from the usual CRUD model where you don’t preserve previous state and override the current state (just writes new values in columns for SQL database).
With event sourcing in place you could re-build your data for particular point in time which could be very useful for data analysis. It also gives you history of every data change by design with no additional coding.
CQS is a code level principle to improve design by applying separation of concerns.
CQRS is application level architectural pattern for separating commands (writes) and queries (reads) in regards to the storage. It is based on the ideas of CQS.
Event Souring is a storage pattern to represent data changes as a stream of events with point-in-time recovery.
CQRS is based on CQS principle and boosted to application level. CQRS is often combined with Event Sourcing and DDD. You can implement CQRS without Event Sourcing. You can implement Event Sourcing without CQRS. Event Sourcing is opposite to the CRUD.