How can I centralize shared user creation logic in a .NET CQRS API using MediatR?

Below is one common solution: move the shared user‐creation logic into a separate domain service or helper so that both command handlers can reuse it while still keeping the transactional boundary. This way you’re not duplicating code and you still encapsulate the business rules in one place. Below are some approaches to consider.

---

1. Using a Domain Service

Rather than having each handler create a User entity manually, you can introduce a domain service (or application service) that encapsulates the process of creating a customer and its associated user(s). For example:

CSHARPCopied
public interface ICustomerAccountManager
{
    Task<Customer> CreateCustomerWithFirstUser(CreateCustomerCommand command, CancellationToken cancellationToken);
    Task<User> AddUserToCustomer(Guid customerId, CancellationToken cancellationToken);
}

public class CustomerAccountManager : ICustomerAccountManager
{
    private readonly DbContext _context;

    public CustomerAccountManager(DbContext context)
    {
        _context = context;
    }

    public async Task<Customer> CreateCustomerWithFirstUser(CreateCustomerCommand command, CancellationToken cancellationToken)
    {
        var customer = new Customer
        {
            Name = command.Name
        };

        await _context.Customers.AddAsync(customer, cancellationToken);

        // Use a helper method to create the User entity.
        var user = CreateUserForCustomer(customer);

        await _context.Users.AddAsync(user, cancellationToken);
        await _context.SaveChangesAsync(cancellationToken);

        return customer;
    }

    public async Task<User> AddUserToCustomer(Guid customerId, CancellationToken cancellationToken)
    {
        var user = new User
        {
            CustomerId = customerId
        };

        // Additional shared user setup can be done here:
        DoAdditionalUserSetup(user);

        await _context.Users.AddAsync(user, cancellationToken);
        await _context.SaveChangesAsync(cancellationToken);

        return user;
    }

    private User CreateUserForCustomer(Customer customer)
    {
        var user = new User
        {
            CustomerId = customer.Guid
        };

        // Additional common logic:
        DoAdditionalUserSetup(user);

        return user;
    }

    private void DoAdditionalUserSetup(User user)
    {
        // Any additional, potentially evolving, user-initialization logic
    }
}

Now your MediatR handlers can simply delegate to this service:

CSHARPCopied
public class CreateCustomerHandler : IRequestHandler<CreateCustomerCommand, Customer>
{
    private readonly ICustomerAccountManager _manager;

    public CreateCustomerHandler(ICustomerAccountManager manager)
    {
        _manager = manager;
    }

    public async Task<Customer> Handle(CreateCustomerCommand request, CancellationToken cancellationToken)
    {
        return await _manager.CreateCustomerWithFirstUser(request, cancellationToken);
    }
}

public class CreateUserHandler : IRequestHandler<CreateUserCommand, User>
{
    private readonly ICustomerAccountManager _manager;

    public CreateUserHandler(ICustomerAccountManager manager)
    {
        _manager = manager;
    }

    public async Task<User> Handle(CreateUserCommand request, CancellationToken cancellationToken)
    {
        return await _manager.AddUserToCustomer(request.CustomerId, cancellationToken);
    }
}

This approach ensures that both handlers are consistent in the way a User is created and maintained. In addition, by having a domain service management the process, you obtain a central location for changes that keeps your code DRY without sacrificing transactional consistency.

---

2. Aggregate Design Consideration

In Domain-Driven Design (DDD), if a customer always owns one or more users and those users are part of the same aggregate, you might consider designing your Customer aggregate so that adding a user is done through the aggregate itself. For example:

CSHARPCopied
public class Customer
{
    public Guid Guid { get; private set; }
    public string Name { get; private set; }
    public List<User> Users { get; private set; } = new List<User>();

    public Customer(string name)
    {
        Guid = Guid.NewGuid();
        Name = name;
    }

    public void AddUser()
    {
        // Here you centralize the User creation logic.
        var user = new User(this.Guid);
        DoAdditionalUserSetup(user);
        Users.Add(user);
    }

    private void DoAdditionalUserSetup(User user)
    {
        // Additional business logic is encapsulated.
    }
}

Then your handler for creating a customer with an associated user might look like:

CSHARPCopied
public class CreateCustomerHandler : IRequestHandler<CreateCustomerCommand, Customer>
{
    private readonly DbContext _context;

    public CreateCustomerHandler(DbContext context)
    {
        _context = context;
    }

    public async Task<Customer> Handle(CreateCustomerCommand request, CancellationToken cancellationToken)
    {
        var customer = new Customer(request.Name);
        customer.AddUser();  // Uses in-aggregate logic for setting up a default user

        _context.Customers.Add(customer);
        await _context.SaveChangesAsync(cancellationToken);

        return customer;
    }
}

This design ensures that the business rules and invariants are enforced within the aggregate boundary, and you won’t need to duplicate any code across handlers.

---

3. Transactional Consistency

One common pitfall in using MediatR events or dispatching additional commands from a handler is the difficulty in maintaining a single transactional boundary. By putting the orchestration logic in a domain service or within your aggregate, you ensure that the database transaction (committed via Entity Framework) encompasses both creating the customer and its associated user(s).

---

Final Thoughts

• The CQRS pattern doesn’t force you to duplicate code, but splitting responsibilities means you need to design your services carefully to avoid code duplication.

• In cases where multiple commands share common business logic, consider centralizing that logic in Domain Services or using properly-designed aggregates.

• This design not only keeps your code DRY but also preserves transactional integrity and enforces business invariants in one place.

By following these approaches, you avoid the pitfalls of executing commands from within commands or having logic spread across multiple handlers, making your codebase more maintainable and consistent.