I think you're speaking more about event-sourcing than CQRS. CQRS is a generic concept that's only about separating writes from reads. It's useful paired with e

I think you're speaking more about event-sourcing than CQRS. CQRS is a generic concept that's only about separating writes from reads. It's useful paired with event-sourcing but on its own it does not suffer these specific drawbacks. Another problem with event sourcing is that there is no easily definable concept of a "field" that can be read from and written to using a named address (contrast with a SQL table column identifier). For a given aggregate, you'll have a single command service that writes a set of "fields" and an unbounded number of query services that receive a copy of that "field" from the event stream and can transform it in any imaginable way. Your "field" may be renamed and moved around through its journey from your command service's API request body to your event's serialized form and to your query service's internal data structures and its final resting place on the query service's persistence data store (mongodb or SQL table or whatever). To identify a field, it's best to use its writable address, and you'll need to come up with your own identifier namespace and naming convention to represent those addresses.