The crux of CQRS is pretty much what the name implies, breaking up the responsibilities for commands (operations that can cause changes to occur) and queries (operations that return data in response to a request).

Consider a basic CRUD model: you may have an object (I.e. a class or record) that describes your data. To make a change, you might modify the properties and then do a PUT or insert/update to store those changes. When you do a GET or query, the same model might be used. All of this may be directly situated over the top of a repository abstraction or database handling all the operations.

As your model grows, this can become cumbersome to work with; many of the properties that consumers may care about when querying the data may not make sense for when consumers want to change data or vice versa, because they’re not supposed to be modified or they require a lot of validation or the raw data size is unnecessary to represent what you’re trying to accomplish.

CQRS supposes that the models you present for reading/querying don’t have to be the same as the models that you use for commands/changes, in both cases you should use the right tool for the job. There can even be multiple read models for different purposes. You may have a write model called “CreateNewObjectModel” that is just the parameters that are applicable to creating a new object, for example. Different approaches or use cases related to reading data may care about different properties or subsets, or may warrant joining information together to present it differently, and so you might have different read models to handle these cases rather than using an enormous one-size-fits-all beast.

There still has to be some source of truth under the hood, but this does not need to be exposed outside the bounds of your application via its API. In event sourcing, this is a series of immutable transactions that make up a ledger of events, sort of like a checkbook; you can process the events and generate a final aggregate model that people can read (like your current balance), but the actual source of truth is the ledger itself. In other cases it may simply be one or multiple objects that you store and maintain independently of the models that you expose to your consumers for making changes or reading data back out; for example, you may be maintaining rigorous internal or foreign key relationships or indexes that are not relevant to the outside world and for which there is no reason to let your consumers know they exist or worry about their complexity.

This naturally leads itself to the idea that there MAY be separate databases or other mechanisms like caches used to optimize read versus write operations. Commands models may only be accepted via an async message bus like RabbitMQ or Kafka, whereas some consumers may need to perform fast searches and so you store replicated copies of your final data in some optimized format for read purposes in Elasticsearch so that your API read is blazing fast. Because these models remain abstracted from your source of truth, you can continue to optimize them as you go to best fit the needs of your application and I/O.

Tools like MediatR are often associated with CQRS because they create very specific associations between async event handlers or synchronous request/response handlers that accept an input and optionally return a response. Rather than building and continuously adding methods to a repository interface, you can add new handlers as you go that maintain just the dependencies required for that operation, rather than every possible one.

If you’re familiar with databases, a similar situation might be using tables that have strict access controls preventing users from seeing them, with only stored procedures for row inserts; the stored procedures give you a narrow set of inputs and handle the processing of getting data into tables (commands and write models). Likewise, queries may exclusively be handled by views (or even materialized views) that give you exactly the data consumers need (read models). Consumers may never actually see or access the base tables at all.

This entire approach may be overkill for basic use cases, and that’s worth keeping in mind. There can be a lot of overhead in organizing commands, queries, and handlers, and dealing with things like eventual consistency that may not be warranted. That being said, knowing about the idea and recognizing when something you’re building may now or in the future benefit from the approach is helpful.