Following the advice in Tackling Complexity in CQRS by Vladik Khononov suggests command handling can return information relating to its outcome.

Without violating any [CQRS] principles, a command can safely return the following data:

• Execution result: success or failure;
• Error messages or validation errors, in case of a failure;
• The aggregate’s new version number, in case of success;

This information will dramatically improve the user experience of your system, because:

• You don’t have to poll an external source for command execution result, you have it right away. It becomes trivial to validate commands, and to return error messages.
• If you want to refresh the displayed data, you can use the aggregate’s new version to determine whether the view model reflects the executed command or not. No more displaying stale data.

Daniel Whittaker advocates returning a "common result" object from a command handler containing this information.

Well, do command handlers return values or not?

They should not return Business Data, only meta data (regarding the success or failure of executing the command). CQRS is CQS taken to a higher level. Even if you would break the purist's rules and return something, what would you return? In CQRS the command handler is a method of an application service that loads the aggregate then calls a method on the aggregate then it persists the aggregate. The intend of the command handler is to modify the aggregate. You wouldn't know what to return that would be independent of the caller. Every command handler caller/client would want to know something else about the new state.

If the command execution is blocking (aka synchronous) then all you would need to know if whether the command executed successfully or not. Then, in a higher layer, you would query the exact thing that you need to know about the new application's state using a query-model that is best fitted to your needs.

Think otherwise, if you return something from a command handler you give it two responsibilities: 1. modify the aggregate state and 2. query some read-model.

Regarding command validation, there are at least two types of command validation:

1. command sanity check, that verifies that a command has the correct data (i.e. an email address is valid); this is done before the command reaches the aggregate, in the command handler (the application service) or in the command constructor;
2. domain invariants check, that is performed inside the aggregate, after the command reaches the aggregate (after a method is called on the aggregate) and it checks that the aggregate can mutate to the new state.

However, if we go some level up, in the Presentation layer (i.e. a REST endpoint), the client of the Application layer, we could return anything and we wont' break the rules because the endpoints are designed after the use cases, you know exactly what you want to return after a command is executed, in every use case.

CQRS and CQS are like microservices and class decomposition: the main idea is the same ("tend to small cohesive modules"), but they lie on different semantic levels.

The point of CQRS is to make write/read models separation; such low-level details like return value from specific method is completely irrelevant.

Take notice on the following Fowler's quote:

The change that CQRS introduces is to split that conceptual model into separate models for update and display, which it refers to as Command and Query respectively following the vocabulary of CommandQuerySeparation.

It is about models, not methods.

Command handler may return anything excepting read models: status (success/failure), generated events (it's primary goal of command handlers, btw: to generate events for the given command), errors. Command handlers very often throw unchecked exception, it is example of output signals from command handlers.

Moreover, author of the term, Greg Young, says that commands are always sync (otherwise, it becomes event): https://groups.google.com/forum/#!topic/dddcqrs/xhJHVxDx2pM

Greg Young

actually I said that an asynchronous command doesn't exist :) its actually another event.

Reply for @Constantin Galbenu, I faced limit.

@Misanthrope And what exactly do you do with those events?

@Constantin Galbenu, in most cases I don't need them as result of the command, of course. In some cases -- I need to notify client in response of this API request.

It's extremely useful when:

1. You need to notify about error via events instead of exceptions. It happens usually when your model need to be saved (for example, it counts number of attempts with wrong code/password) even if error happened. Also, some guys doesn't use exceptions for business errors at all -- only events (http://andrzejonsoftware.blogspot.com/2014/06/custom-exceptions-or-domain-events.html) There is no particular reason to think that throwing business exceptions from command handler is OK, but returning domain events is not.
2. When event happens only with some circumstances inside of your aggregate root.

And I can provide example for the second case. Imagine we make Tinder-like service, we have LikeStranger command. This command MAY result in StrangersWereMatched if we like person who already liked us before. We need to notify mobile client in response whether match was happened or not. If you just want to check matchQueryService after the command, you may find match there, but there is no gurantee that match was happened right now, because SOMETIMES Tinder shows already matched strangers (probably, in unpopulated areas, maybe inconsistency, probably you just have 2nd device, etc.).

Checking response if StrangersWereMatched really happened right now is so straightforward:

$events = $this->commandBus->handle(new LikeStranger(...));


if ($events->contains(StrangersWereMatched::class)) {
return LikeApiResponse::matched();
} else {
return LikeApiResponse::unknown();
}

Yes, you can introduce command id, for example, and make Match read model to keep it:

// ...


$commandId = CommandId::generate();


$events = $this->commandBus->handle(
$commandId,
new LikeStranger($strangerWhoLikesId, $strangerId)
);


$match = $this->matchQueryService->find($strangerWhoLikesId, $strangerId);


if ($match->isResultOfCommand($commandId)) {
return LikeApiResponse::matched();
} else {
return LikeApiResponse::unknown();
}

... but think about it: why do you think that first example with straightforward logic is worse? It doesn't violate CQRS anyway, I just made the implicit explicit. It is stateless immutable approach. Less chances to hit a bug (e.g. if matchQueryService is cached/delayed [not instantly consistent], you have a problem).

Yes, when the fact of matching is not enough and you need to get data for response, you have to use query service. But nothing prevents you to receive events from command handler.