I know this question is old, but one I would like to answer because still relevant today. And I am going to try answer using real world experience rather than text-book theory though I will say that on @Robert Harverys answer referencing Martin Fowler that CQRS fits extremely well with Event Sourcing. I would agree on that and go as far and say that they go hand-in-hand. EventSourcing - CQRS

Short Answer:
All of the successful CQRS implementations I have seen have been on event-based architectures. More specifically using the event sourcing pattern. If used without an event-based design such as Event Sourcing you risk extra complexity in your services. https://medium.com/@mbue/some-thoughts-on-using-cqrs-without-event-sourcing-938b878166a2

How I have seen and have implemented CQRS successfully:
In all projects using the event sourcing pattern. Typically each DDD microservice Aggregate Root would implement CQRS.

The Commands
Having 1 Command Endpoint. (i.e. POST https://customer-service/command). The command endpoint would accept a JSON command say "UpdateCustomer". An aggregate root (Mediator pattern) would validate the command schema and publish the event CustomerUpdated to the event store/hub. Any service interested in customer data will be subscribed, even the same service (customer-service) would listen and form projections in memory, or shared state db (redis, cosmos, sql).

The Read
The service will have normal read endpoints (GET https://customer-service/customers/xxxxxx) and the data would come from the projections of the aggregate of that service.

If planning on using event sourcing here is a great product built for event sourcing from the ground up - Kurrent: https://www.kurrent.io/