I have a .NET WPF smart client calling a .NET WCF web service. The web service does most of the work and returns a small amount of information to the client. As such it's not entirely unlike a browser.
The client calls the web service, and at the moment the web service does some work and returns a "result" object. Things are getting complex, and I think this is because I'm not applying CQS (note I'm talking about CQS not CQRS at this point). I'd like to refactor things to simplify and bring CQS in. I can happily change the WCF contracts still at this point in order to do so.
However, this would suggest that the client application would "send a command message" (i.e. call a command method on the web service), and afterwards would "query" (call a different method on the same web service) for what to do next. It strikes me this is unnecessary; request/response-style is a pretty common style (think of browsers) which, if you think about it, technically breaks CQS. I'm thinking that in my case, providing the operations within the web service and follow CQS, it's okay to cheat the system a bit for the actual web service calls between the two.
Is this acceptable?
Coding design decisions are highly subjective and by not following a strict standard to benefit the application as a whole no one is going berate you.
CQS (Command Query Separation) is nice as it gives you more confidence that the return objects are correct. This works well when accessing objects in memory but in a request/response style system it does become quite chatty (on top of a already very chatty protocol).
If the systems live on the same LAN then I would use CQS. But if you are accessing this over the interwebs or require faster performance then use a regular request/response pattern.