In DDD and CQRS, for Read queries, what is a strat

Question

I'm using PHP/MySQL...

I'm using interfaces for repositories on my Domain "command" side. This is going well. But I'm stuck on what to do on the "queries" (read) side. Do I make queries each as separate methods grouped in classes by some common similarity I find? Or do I make each query its own class? How should I go about using interfaces to make testing (and easier replacement later)?

Some places I've researched:

• A github php example
• An attempt to find the best decoupled approach to the read-side queries. Examples use C# unfortunately and make it a bit more challenging to grasp.

These solutions are convoluted?

Answer 1

We currently use the approach from the second c# link for one of our projects. If you want to use a query facade of some kind, then that's the best one I've come across. What I like most about it is that you create query objects and query handlers, and then a generic query processor does the work of passing the object to the correct handler.

Overall it works well, however it still feels like I'm working harder than I need to. I'm not really sure what this query abstraction is giving me, other than having more to maintain. Testability is often the response to that question, but I for one do not unit test queries. Unit testing in my opinion is best left for code that can potentially break/affect other code. Can a query really break anything that wouldn't be immediately apparent during regular testing? It either works or it doesn't.

If you do have a compelling reason to use a facade, then I recommend grouping the queries that are related into an interface. Such as "IBillingQueries" and "ICustomerQueries".