Question

In wikipedia’s definition of command query separation, it is stated that

More formally, methods should return a value only
if they are referentially transparent
and hence possess no side effects.

If I am issuing a command, how should I determine or report whether that command was successful, since by this definition the function cannot return data?

For example:

string result = _storeService.PurchaseItem(buyer, item);

This call has both a command and query in it, but the query portion is result of the command. I guess I could refactor this using the command pattern, like so:

PurchaseOrder order = CreateNewOrder(buyer, item);
_storeService.PerformPurchase(order);
string result = order.Result;

But this seems like it’s increasing the size and complexity of the code, which is not a very positive direction to refactor towards.

Can someone give me a better way to achieve command-query separation when you need the result of an operation?

Am I missing something here?

Thanks!

Notes:
Martin Fowler has this to say about the limits of cqs CommandQuerySeparation:

Meyer likes to use command-query
separation absolutely, but there are
exceptions. Popping a stack is a good
example of a modifier that modifies
state. Meyer correctly says that you
can avoid having this method, but it
is a useful idiom. So I prefer to
follow this principle when I can, but
I’m prepared to break it to get my
pop.

From his view, it’s almost always worth it to refactor towards command/query separation, except for a few minor simple exceptions.

Answer 1

This question is old but has not received a satisfying answer yet, so I’ll elaborate a bit on my comment from almost a year ago.

Using an event driven architecture makes a lot of sense, not only for achieving clear command/query separation, but also because it opens new architectural choices and usually fits with an asynchronous programming model (useful if you need to scale your architecture). More often than not, you will find the solution may lie in modelling your domain differently.

So let’s take your purchase example. StoreService.ProcessPurchase would be a suitable command for processing a purchase. This would generate a PurchaseReceipt. This is a better way instead of returning the receipt in Order.Result. To keep things very simple, you can return the receipt from the command and violate CQRS here. If you want a cleaner separation, the command would raise a ReceiptGenerated event that you can subscribe to.

If you think about your domain, this may actually be a better model. When you’re checking out at a cashier, you follow this process. Before your receipt is generated, a credit card check might be due. This is likely to take longer. In a synchronous scenario, you would wait at the cashier, unable to do anything else.