Question

I read that commands in CQRS are designed to not fail and should be async in nature.

In my case, I have a tree (think windows explorer) where users have folders that represent locations for video content and each child is a video/media file. Multiple users can all be working on the same branch of the tree moving folders and files around (and uploading new files and creating new folders as well as deleting files/folders).

If I was ignoring the async nature of commands, I could let the first user make their change and raise an exception on the second if say a folder the user is moving a video to is no longer there. It is now the responsibility of the second user to refresh part of his tree and then reapply his changes.

How would I do this with CQRS if I need instant feed back if my change has not been allowed (i.e. I try to move a video file to another folder and another user has deleted the folder or moved it elsewhere)?

Answer 1

Your command is supposed to be valid when you send it to your domain. Therefore, before sending it, you have to validate it on your client to know if the folder is still here or not. It allows you to tell the client what is happening exactly with a clear error message

This reduces also a lot the margin of error.The timeframe to have something that fails is reduced to the time to send the command over the network and the time to execute the command on the server.

• If this risks is really low. We may only receive a fail command
  answer (eg:enum) from the domain. For the user, it might end up in a
  generic exception message and we could actualize its data to show him
  that things are different and taht he cannot do what he intended to.
  Such messages with a low percentage should not be a huge problem if
  they occurs only 2-3 times in the year , I expect.

• If this risks is really high or if validation is not possible from
  the client but must occur only on the domain side, then I have no
  answer to give you at the moment. I am myself learning CQRS, and i
  cannot say more.

hope it helped,

[Edit]

I assumed command handling not to be async. If So, I try catch whatever exception during execution of the command and I can return some fail notification without saying what it is exactly to the client. The projection to the various readmodel remaining async.

 public void Handle(ICommand command)
        {
            try
            {
                CommandService.Execute(command);

                Bus.Return(ErrorCodes.None);
            }
            catch (Exception e)
            {
                Bus.Return(ErrorCodes.Fail);
            }
        }

My CommandServiceDelegate the right executor to do the job :

Public class TheGoodExecutor{
      protected void Execute(IUOW context, MyCommand command)
        {
            var myDomainObject= context.GetById<DomainObjecType>(command.Id);

            myDomainObject.DoStuff(Command.Data);

            // Accept all the work we just did.
            context.Accept();
        }
}

If the good Executor goes in error then Bus.Return(ErrorCodes.Fail);

And this can be received by my client either synchronously or asynchronously.

If you wish to go full async (that’s what I am trying to do, or at least I would like to explore that way), I would try on subscribing to events, the client might be interested in.
For Validation I think, listening to events does not make a lot of sense for most of the cases. But in the second case, I was speaking of, it might. In other cases, aside validation, it might too…

everything in Italic is some personal tryout, I have not read anything about it, nor finished anything working properly going in that sense. So take it with Big brackets.. he he!!

[/Edit]