Nested mediatR calls

[ayuksekkaya]

Hello? thank you for this great work. I am going through the codebas and playing around with the product in general. I see that we are doing some nested mediatR calls. Calling "send" from inside a Handle method. For example in the Tenant Creation command. My understanding was that injecting mediatR through DI to another handler like you are doing can cause concurrency issues and will create a new ef change tracker. Also noted here

https://stackoverflow.com/questions/49042123/is-it-ok-to-have-one-handler-call-another-when-using-mediatr

Is this not the case? If so, should it be refactored?

[tjementum]

Hi @ayuksekkaya,

Thanks for the comments and a great question.

In the article linked by your StackOverflow post Jimmy Bogard points out that while using nested MediatR calls can add complexity and that he is not a fan, there’s no definitive rule against it. It depends on understanding and managing the trade-offs.

While I see why some would say that commands should not send other commands, encapsulating all data changes within commands ensures single responsibility. This way, it’s clear where and how something like user creation is being handled. Moving this logic outside the CreateUserCommand into, for example a UserService risks making the code fragile, less predictable, and can easily result in big “god classes” (e.g., UserService could become very big). IMO, this defeats the whole point of CQRS. So, I would only do this in very complex scenarios.

I favor consistency, and I find that most CRUD operations can be created following this pattern:

1. Command record (the API). A record like CreateTenantCommand.
2. Input validation with FluentValidation. A class like CreateTenantValidator.
3. A command handler like CreateTenantHandler, which has this flow:
   a. Guards that checks the state and returns a failed result response (don't use exceptions).
   b. Make changes to domain entities. This might, in turn, create a new "domain event" like TenantCreatedEvent, which will be handled in step 4 (in the same transaction).
   c. Update repository. In PlatformPlatform, Entity Framework tracking has deliberately been disabled, so this is an explicit step.
   d. Call other commands. For example, send a CreateUserCommand within CreateTenantHandler to create the Owner User.
   e. Collect user behavior telemetry items. These are not a programming concept but are used to understand user behavior and track business metrics. All changes to the system should, IMO, raise one telemetry item, and commands are the perfect place for this.
   f. Return the Id of the resource created, like TenantId.
4. Handle any domain events like TenantCreatedEvent (from 3.a). This will start a nested MediatR pipeline.
5. Commit any changes to domain entities in a transaction using UnitOfWork.Commit() and log the collected telemetry items to Application Insights. In PlatformPlatform, the MediatR pipeline behaviors are configured to commit only when the outer pipeline and all nested commands have successfully completed.
6. Not yet implemented: Raise "integration events" using the outbox pattern that will be consumed by other self-contained systems.

Consistently trying to follow this makes the codebase very easy to extend and reason about. It might sound complicated, but the code below shows it's very simple.

[PublicAPI]
public sealed record CreateTenantCommand(TenantId Id, string OwnerEmail, bool EmailConfirmed)
    : ICommand, IRequest<Result<TenantId>>;

public sealed class CreateTenantValidator : AbstractValidator<CreateTenantCommand>
{
    public CreateTenantValidator()
    {
        RuleFor(x => x.OwnerEmail).NotEmpty().SetValidator(new SharedValidations.Email());
    }
}

public sealed class CreateTenantHandler(ITenantRepository tenantRepository, IMediator mediator, ITelemetryEventsCollector events)
    : IRequestHandler<CreateTenantCommand, Result<TenantId>>
{
    public async Task<Result<TenantId>> Handle(CreateTenantCommand command, CancellationToken cancellationToken)
    {
        if(await tenantRepository.ExistsAsync(command.Id, cancellationToken))
        {
            return Result<TenantId>.Conflict("Tenant already exists.");
        }
        
        var tenant = Tenant.Create(command.Id, command.OwnerEmail);

        await tenantRepository.AddAsync(tenant, cancellationToken);

        events.CollectEvent(new TenantCreated(tenant.Id, tenant.State));

        await mediator.Send(new CreateUserCommand(tenant.Id, command.OwnerEmail, UserRole.Owner, command.EmailConfirmed), cancellationToken);

        return tenant.Id;
    }
}

I would say it’s very clear what’s going on here. This way, for example, the CreateUserCommand can be called from many places, without duplicating any logic. And I really like that each command fully adheres to the Single Responsibility Principle (SRP).

It might feel “magical” when the UnitOfWork is actually committed and changes are saved to the database. In many implementations, I see a DbContext.SaveChangesAsync() as the last line in the command handler. But this is the point: when having nested MediatR pipelines, data is actually not committed here but only after the outer command and all nested pipelines have successfully completed.

I recently switched PlatformPlatform from Clean Architecture to Vertical Slice Architecture, which has simplified the code. In Clean Architecture, logic was spread across different layers, and I used domain events to handle, for example, the creation of an Owner user when a tenant was created. In Vertical Slice Architecture, it is much easier to create a full vertical slice in one file, and having one command call another makes it very clear what is going on without having to duplicate domain logic or move logic out of a command.

I don’t see any mention of concurrency problems in your link, and I don’t see why there should be any. MediatR is very predictable in how it handles events. Regarding the risk of infinite loops mentioned in the article, it’s an issue present in any form of nested calls—commands, services, or otherwise. I don't recall ever facing such a problem in a production system in my 30 years of building production-grade software.

All that said, I would strive to avoid multiple nested layers of commands calling commands. No architecture can fully enforce good design choices, and developers must still use sound judgment to avoid bad patterns.

[ayuksekkaya]

I see yes that makes a lot of sense. I like this approach too. I was just surpirsed because in other applications I think this specific example you gave would be handled by creating a domain event like you described and handling the "owner" creation there.

So if we are calling the other handler directly, when would we use the "notify" pattern here?