Oskar Dudycz

Pragmatycznie o programowaniu

How to register all CQRS handlers by convention

2021-11-24 oskar dudyczCQRS

cover

In CQRS, it’s common to define interfaces for the handlers to enforce the unified code structure. Such an approach is used, e.g. by MediatR library. It is a simple, in-memory implementation of the Mediator pattern. Even if you’re not using any libraries but handmade tools and you’re in the .NET or Java land, you may want to walk that way. It’s a longer discussion if DI is really needed. I may write a dedicated post around it, but today let’s assume that’s your desired approach.

Registering handlers manually has benefits. You can use code as documentation of what you’re handling. Still, in some cases, it may become tedious, especially when working with a huge monolith. Also, sometimes you just want to have your life easier a bit. Kristian Hellang created Scrutor library that makes assembly scanning and DI registration extremely simple. Before we see how Scrutor can help us, have a look at the manual way.

Let’s define a few interfaces for handling:

public interface ICommandHandler<in T>
{
    ValueTask Handle(T command, CancellationToken token);
}

public interface IQueryHandler<in T, TResult>
{
    ValueTask<TResult> Handle(T query, CancellationToken ct);
}

public interface IEventHandler<T>
{
    ValueTask Handle<T>(T event, CancellationToken token);
}

If we did manual registration, we could define the following methods:

public static class Config
{
    public static IServiceCollection AddCommandHandler<TCommand, TCommandHandler>(
        this IServiceCollection services
    )
        where TCommandHandler : class, ICommandHandler<TCommand>
    {
        return services.AddTransient<TCommandHandler>()
            .AddTransient<ICommandHandler<TCommand>>(sp => sp.GetRequiredService<TCommandHandler>());
    }
    
    public static IServiceCollection AddQueryHandler<TQuery, TQueryResult, TQueryHandler>(
        this IServiceCollection services
    )
        where TQueryHandler : class, IQueryHandler<TQuery, TQueryResult>
    {
        return services.AddTransient<TQueryHandler>()
            .AddTransient<IQueryHandler<TQuery, TQueryResult>>(sp => sp.GetRequiredService<TQueryHandler>());
    }
    
    public static IServiceCollection AddEventHandler<TEvent, TEventHandler>(
        this IServiceCollection services
    )
        where TEventHandler : class, IEventHandler<TEvent>
    {
        return services.AddTransient<TEventHandler>()
            .AddTransient<IEventHandler<TEvent>>(sp => sp.GetRequiredService<TEventHandler>());
    }
}

We could use them like that:

internal static class CartsConfig
{
    private static void AddHandlers(IServiceCollection services)
    {
        services.AddCommandHandler<InitializeCart, HandleInitializeCart>()
                .AddCommandHandler<AddProduct, HandleAddProduct>()
                .AddQueryHandler<GetCartById, CartDetails?, HandleGetCartById>()
                .AddQueryHandler<GetCartAtVersion, CartDetails, HandleGetCartAtVersion>()
                .AddEventHandler<CartConfirmed, HandleCartFinalized>();
    }
}

That doesn’t look bad, but such config, if not appropriately controlled, can grow exponentially (check How to slice the codebase effectively? to know how to tame it).

Let’s see how we could use Scrutor to register all of our handlers automatically.

public static class Config
{
    public static IServiceCollection AddAllCommandHandlers(
        this IServiceCollection services,
        ServiceLifetime withLifetime = ServiceLifetime.Transient,
        AssemblySelector from = AssemblySelector.ApplicationDependencies)
    {
        return services.Scan(scan => scan
            .FromAssemblies(from)
            .AddClasses(classes =>
                classes.AssignableTo(typeof(ICommandHandler<>))
                    .Where(c => !c.IsAbstract && !c.IsGenericTypeDefinition))
            .AsSelfWithInterfaces()
            .WithLifetime(withLifetime)
        );
    }

    public static IServiceCollection AddAllQueryHandlers(
        this IServiceCollection services,
        ServiceLifetime withLifetime = ServiceLifetime.Transient,
        AssemblySelector from = AssemblySelector.ApplicationDependencies)
    {
        return services.Scan(scan => scan
            .FromAssemblies(from)
            .AddClasses(classes =>
                classes.AssignableTo(typeof(IQueryHandler<,>))
                    .Where(c => !c.IsAbstract && !c.IsGenericTypeDefinition))
            .AsSelfWithInterfaces()
            .WithLifetime(withLifetime)
        );
    }

    public static IServiceCollection AddAllEventHandlers(
        this IServiceCollection services,
        ServiceLifetime withLifetime = ServiceLifetime.Transient,
        AssemblySelector from = AssemblySelector.ApplicationDependencies)
    {
        return services.Scan(scan => scan
            .FromAssemblies(from)
            .AddClasses(classes =>
                classes.AssignableTo(typeof(IEventHandler<>))
                    .Where(c => !c.IsAbstract && !c.IsGenericTypeDefinition))
            .AsSelfWithInterfaces()
            .WithLifetime(withLifetime)
        );
    }
}

Scrutor allows us to define which assemblies we want to scan by calling the FromAssemblies method. We can select only our application dependencies with AssemblySelector.ApplicationDependencies.

Then we can register implementations by calling AddClasses and selecting which we’d like to use. In our case, those will be not abstract, not generic classes implementing the particular interface (ICommandHandler, IQueryHandler, IEventHandler). We’re adding that condition not to register base classes or generic handlers. If we have such, then we should instead set them up manually.

Then we can state that we want to register the handler as itself (so specific class) and all the interfaces it implements. Then we can call those methods in our application setup:

services.AddAllCommandHandlers()
    .AddAllQueryHandlers()
    .AddAllEventHandlers();

Such an approach will both work for custom handling like, e.g.:

public static class CommandBus
{
    public static ICommandHandler<T> GetCommandHandler<T>(this HttpContext context)
        => context.RequestServices.GetRequiredService<ICommandHandler<T>>();


    public static ValueTask SendCommand<T>(this HttpContext context, T command)
        => context.GetCommandHandler<T>()
            .Handle(command, context.RequestAborted);
}

You can expand it with decorators, etc., to build your pipelines and decorate handling with middlewares.

Et voilà!

Cheers!

Oskar

p.s. if you liked this article, then check also similar:

👋 If you found this article helpful and want to get notification about the next one, subscribe to Architecture Weekly.

✉️ Join over 11500 subscribers, get the best resources to boost your skills, and stay updated with Software Architecture trends!

Loading...
Event-Driven by Oskar Dudycz

cover

Through my window, I see the result of good plans but poor execution. Opposite my flat, there is a partially completed construction place. Buildings were supposed to be eye-catching Mediterranean style apartments. Delivery date? Two years ago. Actual? More and more unknown.

Some time ago, I heard that using Event Sourcing makes creating Event-Driven Architecture easier. The arguments were correct, that if we’re already publishing events to trigger business workflows, then at some point, we may want to also store events to not lose information. Agreed. However, I also heard that keeping the state as events will simplify things. We’ll have a source of truth with a record of the system behaviour. This will allow, e.g. to confront the results of the operations with the recorded state. I’d agree with that, with one distinction. It’s easier as long as you already know Event Sourcing.

Many people in the DDD community claim that the essential is to properly break down the system into autonomous parts called bounded contexts. Once we have it, the rest is secondary and will sort itself out. For sure.

Many seasoned programmers speak similarly about new technologies. They claim that they can translate past experience into new technologies. That’s true that by analogy, they can catch the big picture quicker. But isn’t it a bold assumption to say that Win.Forms specialist will learn Angular quickly?

The end result may differ a lot from the initial ideas. I saw the plan of those buildings next to me. Now I can see the effects of the execution. Or actually, the lack.

I believe that we should carefully acknowledge not only the point of view of our authorities but also their seating point. If we want to find out how to form a wall, do we ask an architect or a foreman? An architect may know the theory, but the practice is what we’re looking for. On the other hand, if you want to know where to put the wall, you prefer the architect to do measurements. At least if you don’t want to have the roof falling to your head.

After I had torn a ligament in my knee, I went to two qualified orthopedists. One said I should have surgery and do a reconstruction. The second stated that there is no need for that; rehabilitation should be enough. Guess which one had a specialization in surgery and which in rehabilitation?

People usually give us advice from the point where they’re currently standing. They are entitled to a biased view. An architect who rarely does programming will tend to downplay the value of implementation and tactical patterns. Midlevel developers will focus on technicalities instead of the global system impact. The team manager or consultant will emphasize the importance of soft skills (or esoteric techniques known only to them).

The truth is that we need all of them. The excellent plan will fall on the bad execution. The best execution for the wrong case will be just a waste of time. We should carefully evaluate the advice considering what we need and what an expert can give us.

Therefore, when we’re reading an article, watching a talk, let’s also pay attention to the place where the person is standing. The perspective from there may be much different from where we are right now. That can be good, as it may push us in the right direction. But it may also be misleading, as we accidentally take biases of this person without understanding the tradeoffs. Personally, I prefer to follow not only people from pedestal but also those that are closer to my position. A bit further in the journey, but not too far. That helps me to calibrate my view as those people are more relative to my daily struggles.

Polish historical leader Józef Piłsudzki reportedly used to say: “Right is like an ass, everyone has its own”.

Cheers!

Oskar