CQRS/ES stands for Command Query Responsibility Segregation. DDD stands for Domain Driven Design. A team of mine has been working with these for the last year and a half. Here are some of the questions I have answered regularly.
What are some practical risks of returning the domain model directly to a client application such as the front-end?
Returning the domain model to a client application (such as the front-end) has several risks including 1. extra change approval overhead, 2. leaking secure data, and 3. difficulty maintaining and reasoning about the domain.
First, the back-end developers are going to have to make a change approval request to the front-end before changing their domain models; if they do not do that, the back-end developers might change the domain model and inadvertently break the front-end code. This change approval process prevents innovation on the back-end, because often the change approval process takes too long and results in needless discussion.
Second, there is a security risk to returning the domain model directly to the client application, because something stored in the back-end might not be appropriate for client application to see.
Third, returning the domain model directly to the client application encourages the domain model to take on inappropriate responsibilities. In domain driven development, the domain model is responsible for modeling the domain. When the domain starts also to concern itself with client application responsibilities, then the domain model can become needlessly complex. In its extreme form, a domain that is modeling sea level rise (for instance) might start to have properties, such as htmlLabel, which are not necessary for modeling the domain. Other subtle leaking of responsibilities can happen, too, such as changing the name of a property to something the client application expects.
Software development is complex enough already; lets follow the single responsibility principle by keeping the domain model about the domain. If you find yourself having coupled the domain model to the client application, then consider simply renaming the domain model to a "materialized view model", which is more descriptive of the role the models have come to be performing. Then get busy also building a new, clean domain model with a single responsibility.
Should CQRS command execution return query results to the client application? If not, why not?
According to CQRS principles, command execution should not return query results to the client application. Instead, command execution should only return command metadata relating to the command's outcome. Appropriate command metadata includes validation results (that command is not okay to execute) and fulfillment results (e.g. an identifier or version that indicates where to find the updated aggregate).
Why? We avoid returning query information from a command, because different clients might want different data after command execution completes. Even the same client might want different data after command execution completes. For instance, after running the CreateInvoiceCommand, a client application might sometimes want to see a list of all customers, and might other times want to see a list of a certain customer's unpaid invoices. In short, the return value of the command execution should be independent of the client application that is calling the command.
Here are some references about what command execution should return: