From martinfowler.com on "Command Query Responsibility Segregation", or CQRS:
The mainstream approach people use for interacting with an information system is to treat it as a CRUD datastore. By this I mean that we have mental model of some record structure where we can create new records, read records, update existing records, and delete records when we're done with them. In the simplest case, our interactions are all about storing and retrieving these records.
As our needs become more sophisticated we steadily move away from that model. We may want to look at the information in a different way to the record store, perhaps collapsing multiple records into one, or forming virtual records by combining information for different places. On the update side we may find validation rules that only allow certain combinations of data to be stored, or may even infer data to be stored that's different from that we provide.
As this occurs we begin to see multiple representations of information. When users interact with the information they use various presentations of this information, each of which is a different representation...
This structure of multiple layers of representation can get quite complicated, but when people do this they still resolve it down to a single conceptual representation which acts as a conceptual integration point between all the presentations.
The change that CQRS introduces is to split that conceptual model into separate models for update and display, which it refers to as Command and Query respectively following the vocabulary of CommandQuerySeparation. The rationale is that for many problems, particularly in more complicated domains, having the same conceptual model for commands and queries leads to a more complex model that does neither well.
I saw this acronym for the first time today in a SO question about Azure Service Fabric, and my HOT TAKE!!11! was, "Who in the world doesn't do this?"
There are two main data transformations that happen in essentially all of my controller code. For GETs, I'm usually flattening a "database is truth" model into a data payload, stripped of stuff like, "LastModifiedBy" (or anything not needed by the client), but also of complex relationships with child objects. That is, when Entity Framework (or any POCO-returning library) gives me, say, an address' stateOrProvince as an entity, I usually flatten that to a StateName and StateId at the top level of a client-ready DTO for Addresses (or at the Address level on a collection of Addresses attached to a client).
The second is when I return changes to these DTOs. There, the PUT (or PATCH) command often isn't strictly RESTful either [using the database as The Source of Truth]. If I'm returning the ever-proverbial Contact with three Addresses, I don't typically call an Addresses endpoint with a PUT thrice, and then follow up with another PUT to Contacts. I'll send up a DTO that's essentially CompositeContactWithAddressesAndOtherJive (but with a better name, like ContactDTO). And though if I'm trying to keep our stack small in cases where team familiarity with SQL isn't a strong suit, I will, occasionally, still hit EF repository collections, I usually prefer to write the INSERT/UPDATE SQL by hand and perform what needs doing in as few optimized calls as possible. The move away from the ORM for PUTs hurts if you ever want to swap out your database engine, of course, but who swaps out their database engine? Talk about premature optimizations. Why should nearly every PUT suffer when you're likely hiring for SQL proficiency? For a clean object model? Stop it. Use your team's skills.
There is nothing that, in my experience, causes performance bottlenecks as quickly as folks blindly falling back on performing Commands (actions that "Change the state of a system but do not return a value") via fully hydrated ORM objects. Oh, the humanity.
Treating your PUTs and PATCHes as separate models from your GETs (or at least separate models from those in your database schema) allows you to spare yourself such madness.