Command Handling Pattern Part 4

Decorators

Now that I have a command dispatcher I have decoupled the issuing of the command from the handling of the command. This means that I can change how and where a command is handled without affecting clients.

This led me to the idea of using decorators to add functionality to the handling of a command, and the implementation of cross-cutting  concerns is an obvious starting point.

There are various cross-cutting concerns that should be implemented outside of the core handler, and most obvious one to implement is logging.

Logging

The ability to log the execution of a command without any code in the handler itself is really useful. Which is what following class does (the actual Log.... methods just write to the _logger field):

public class LoggingDecorator<T> : ICommandHandler<T>
{
    private readonly ICommandHandler<T> _wrappedHandler;
    private readonly ILogger<ICommandHandler<T>> _logger;

    public LoggingDecorator(
        ICommandHandler<T> wrappedHandler,
        ILogger<ICommandHandler<T>> logger)
    {
        _wrappedHandler = wrappedHandler;
        _logger = logger;
    }

    public async Task<CommandResult> HandleAsync(T command)
    {
        LogEntry(command);
        var result = await _wrappedHandler.HandleAsync(command, cancellationToken);
        if (!result.IsSuccess)
        {
            LogFailure(command, result);
        }
        LogExit(command);

        return result;
    }
}

When the command dispatcher is about to send a command to the appropriate handler, it creates a LoggingDecorator instance to wrap it, so the execution of all commands get logged, along with any errors.

Exception Handling

Another basic cross-cutting concern is exception handling. The command handler (or command handling pipeline) is at the boundary of the domain, so it sometimes makes sense to prevent any exceptions bubbling up to outer layers. So an exception handling decorator can be useful as one of the outer handlers.

public class ExceptionHandlingDecorator<T> : ICommandHandler<T>
{
    private readonly ICommandHandler<T> _wrappedHandler;

    public ExceptionHandlingDecorator(
        ICommandHandler<T> wrappedHandler)
    {
        _wrappedHandler = wrappedHandler;
    }

    public async Task<CommandResult> HandleAsync(T command)
    {
        try
        {
            return await _wrappedHandler.HandleAsync(command);
        }
        catch (Exception exception)
        {
            return CommandResult.Error(exception.ToString());
        }
    }
}

Any exception that occurs anywhere during the handling of a command is caught and returned as a CommandResult, so clients always get a known type of result.

It's obviously useful to log exceptions as they're caught, so either the LoggingDecorator can be the outermost handler (and will therefore log exceptions as the error contained within the CommandResult object), or the ExceptionHandlingDecorator can take a logger as a dependency to log the exception in the catch block.

Validation

Validation is something that almost every handler needs to perform on the incoming command. What if this could be extracted out into another decorator so that each core handler can just focus on the actual business logic to be executed?

This isn't as simple as logging, as validation is obviously different for every command. So there's an interface to be implemented for any command requiring validation, and then a decorator that takes an instance of that interface. Like this:

public interface ICommandValidator<T>
{
    Task<CommandResult> ValidateAsync(T command);
}

public class ValidatingDecorator<T> : ICommandHandler<T>
{
    private readonly ICommandHandler<T> _wrappedHandler;
    private readonly ICommandValidator<T> _commandValidator;

    public ValidatingDecorator(
        ICommandHandler<T> wrappedHandler,
        ICommandValidator<T> commandValidator)
    {
        _wrappedHandler = wrappedHandler;
        _commandValidator = commandValidator;
    }

    public async Task<CommandResult> HandleAsync(T command)
    {
        var validationResult = await _commandValidator.ValidateAsync(command);
        if (!validationResult.IsSuccess)
        {
            return validationResult;
        }

        return await _wrappedHandler.HandleAsync(command);
    }
}

 

What's Next?

There are a few more decorators that I've used to good effect, so the next blog post will be about two of them: a pre-processing decorator and a post-processing decorator. Til next time!

Command Handling Pattern Part 3

A Command Dispatcher

 

The approach outlined in the previous post is fine, however there are a few limitations. One is that clients that need to issue several commands will have a proliferation of dependencies. For example, even in a simple CRUD application, a controller for a particular entity will likely have to Create, Update and Delete instances of that entity. Each of these operations will be a command, so the controller will need a handler for each command. For example:

public class CustomersController : Controller
{
    private readonly ICommandHandler<AddCustomer> _addCustomerHandler;
    private readonly ICommandHandler<EditCustomer> _editCustomerHandler;
    private readonly ICommandHandler<DeleteCustomer> _deleteCustomerHandler;

    public CustomersController(
        ICommandHandler<AddCustomer> _addCustomerHandler,
        ICommandHandler<EditCustomer> _editCustomerHandler,
        ICommandHandler<DeleteCustomer> _deleteCustomerHandler)
    {
        // assign fields
    }

    // More code here
}

This can quickly get out of hand, and when looking at the dependencies for a particular class it's enough to know that they issue commands without knowing the specific commands that are issued. It's usually clear from the context which entity is being operated on anyway.

So a single class that can accept any command and dispatch it to the appropriate handler seemed like a good idea. That would make the above controller code much more concise:

public class CustomersController : Controller
{
    private readonly ICommandDispatcher _commandDispatcher;

    public CustomersController(ICommandDispatcher commandDispatcher)
    {
        _commandDispatcher = commandDispatcher;
    }

    // More code here
}

Here is an initial implementation of the command dispatcher itself. Note it uses the application's IoC container to get the correct command handler (I'm using the IServiceProvider that comes with AspNetCore). This may be an anti-pattern to some (Service Locator anyone?) but the dispatcher needs to be able to instantiate any handler in the system.

public class CommandDispatcher : ICommandDispatcher
{
    private readonly IServiceProvider _serviceProvider;

    public CommandDispatcher(IServiceProvider serviceProvider)
    {
        _serviceProvider = serviceProvider;
    }

    public async Task<CommandResult> ExecuteAsync<T>(T command)
    {
        var handler = _serviceProvider.GetService<ICommandHandler<T>>();
        // Null checks

        return await handler.HandleAsync(command);
    }
}

The dispatcher simply gets the required handler from the IoC container and then passes it the command to be handled. If this was all it did then I probably would class it as an anti-pattern and consign it to the dustbin. However now that all clients will depend on the dispatcher rather than individual handlers, it means that additional processing can be introduced outside of the handler and be run with every request. This is particularly useful for cross-cutting concerns like logging and exception handling, and for me is the major attraction of this approach. I'll spend the next couple of posts going through some examples.

Command Handling Pattern Part 2

The Simple Approach

 

Commands

A Command is a class that contains the data required to perform the business process. For example you might have an EditCustomerName Command that contains the ID of the Customer to be edited and their new name.

public class EditCustomerName : ICommand
{
    public int CustomerId { get; set; }
    public string NewName { get; set; }
}

Handlers

Each Command is handled by a (you guessed it) Command Handler. To handle the above Command we might have something like this:

public class EditCustomerNameHandler : ICommandHandler<EditCustomerName>
{
    public async Task HandleAsync(EditCustomerName command)
    {
        // Do stuff
    }
}

This leads to much more focused code as each handler is responsible for just one business process. So if there are seven different operations that can be performed on a Customer, there will be seven different Handlers, each responsible for its own Command. In the service approach, the CustomerService would have had seven (unrelated) methods, which leads to hard to understand (and therefore hard to maintain) code.

Results

Strict interpretations of the Command Pattern often say that you shouldn't return anything from the processing of a Command. I find this to be unrealistic as it's often necessary to communicate (at the very least) the success or failure of the operation. So for the simple approach the return object (including convenience factory methods) I used was this:

public class CommandResult
{
    public bool IsSuccess { get; }
    public IEnumerable<string> Errors { get; }

    public CommandResult(bool isSuccess, params string[] errors)
    {
        IsSuccess = isSuccess;
        Errors = errors;
    }

    public static CommandResult Success()
    {
        return new CommandResult(true);
    }

    public static CommandResult Error(params string[] errors)
    {
        return new CommandResult(false, errors);
    }
}

Summing Up

Pulling together the ideas above we can define a Command Handler interface as follows:

public interface ICommandHandler<T> where T : ICommand
{
    Task<CommandResult> HandleAsync(EditCustomerName command);
}

This simple approach allows each business process to be handled by its own class, and for any errors to be communicated back to the client.

There are however a number of limitations, such as difficulty composing different Command Handlers together and no way to communicate data back to client. I'll look to address these limitations in the next few posts.

Command Handling Pattern Part 1

The Problem to be Solved

I've spent a lot of time over the past few years writing line-of-business applications in various industries, and I never felt entirely comfortable with how I structured business logic. I generally used entity-based services - e.g. a Product Service that operates on a Product entity - and the problem that I saw again and again with this approach is that the service ends up a bloated, unfocused mess: the 'God' service that knows and does everything.

So I went searching for alternatives and decided to start using a Command Handling Pattern. The central idea is that a business process that needs to be performed (i.e. writes not reads) is represented by a Command (this is similar to, but not exactly the same as, the traditional Command Pattern).

I'm planning on writing a series of posts to explore how my ideas evolved from a fairly simple pattern to a more complex solution taking ideas from the Chain of Responsibility Pattern.

Next time I'll go into the first step on this journey. Watch this space!