I’ve read about CQRS systems that maintain a simple key value store on the command side to represent an application’s state, and others that merely correlate messages (using some sort of saga) and utilise the query store to represent an applications state instead. Either way there’ll no doubt be a persistence technology involved with these approaches, but the repository pattern in these cases would be an unnecessary abstraction over the top of it.
My experience with CQRS has only ever been with event sourcing though, where we’ve replayed past events to rebuild aggregates that encapsulate and enforce business logic and invariants. In this case the repository pattern is a familiar abstraction that can provide a simpler way of retrieving any of these aggregates.
With regards to the query side I’d recommend getting as close to the data store as possible, by this I mean avoid any repositories, services or facades etc. between your UI (whatever that may be) and your data store.
It might help to see an example of these approaches in use. Maybe take a look at the following projects:
- https://github.com/gregoryyoung/m-r/tree/master/SimpleCQRS
- https://github.com/MarkNijhof/Fohjin
- https://github.com/elliotritchie/NES
- https://github.com/ToJans/Scritchy
- http://ncqrs.org
In the case of NES the repository merely provides a familiar interface for adding and reading aggregates directly to and from the unit of work.
Some more links that might help:
- CQRS Examples and Screencasts
- Event Sourcing Resources