CODEWITHSUNDEEP
domain-driven-designcqrs
user1075940
user1075940

Reputation: 1125

external service result mutates state of aggregate

My problem is that I don't know how to handle external calls that mutates the state but also needs validation before executing them

Here is my command handler

public async Task<IAggregateRoot> ExecuteAsync(Command command)
{
    var sandbox = await _aggregateStore.GetByIdAsync<Sandbox>(command.SandboxId);
    var response = await _azureService.CreateRedisInstance(sandbox.Id);
    if (response.IsSuccess)
    {
        sandbox.CreateRedisDetails(response);
        return sandbox;
    }

    sandbox.FailSetup(response.Errors.Select(e => e.Message));
    return sandbox;
}

The problem here is that the sandbox aggregate needs to be in correct state before calling external service and I cannot satisfy both. My only idea here is to create separate method CanCreateRedisInstance that checks if aggregate state is valid and only then calls external service. What I don't like is that I introduce validation methods

public async Task<IAggregateRoot> ExecuteAsync(Command command)
{
    var sandbox = await _aggregateStore.GetByIdAsync<Sandbox>(command.SandboxId);
    if(!sandbox.CanCreateRedisInstance())
    {
       throw new ValidationExcetpion("something");
    }

    var response = await _azureService.CreateRedisInstance(sandbox.Id);
    if (response.IsSuccess)
    {
        sandbox.CreateRedisDetails(response);
        return sandbox;
    }

    sandbox.FailSetup(response.Errors.Select(e => e.Message));
    return sandbox;
}

The other approach I thought of is to make whole process more cqrs-ish.

public async Task<IAggregateRoot> ExecuteAsync(Command command)
{
    var sandbox = await _aggregateStore.GetByIdAsync<Sandbox>(command.SandboxId);
    sandbox.ScheduleRedisInstanceCreation();
}

public void ScheduleRedisInstanceCreation()
{
  if(RedisInstanceDetails != null)
  {
     throw new ValidationException("something")
  }
  RedisInstanceDetails = RedisInstanceDetails.Scheduled(some arguments);
  AddEvent(new RedisInstanceCreationScheduled(some arguments));
}

The RedisInstanceCreationScheduled event is sent to queue and picked by event handler which will call external service and based on result will create other events

public async Task ExecuteAsync(RedisInstanceCreationScheduled event)
{
    var sandbox = await _aggregateStore.GetByIdAsync<Sandbox>(command.SandboxId);
    var response = await _azureService.CreateRedisInstance(sandbox.Id);
    if (response.IsSuccess)
    {
        sandbox.CreateRedisDetails(response);
        return sandbox;
    }

    sandbox.FailSetup(response.Errors.Select(e => e.Message));
   _aggregateStore.Save(sandbox);
}

However this approach add some extra complexity and I am not quite sure if event handler should modify aggregate.

Upvotes: 0

Views: 71

Answers (1)

Luca Masera
Luca Masera

Reputation: 732

Both approaches are possible.

Why no validation should stay in the Handler? When you change something in the domain, the domain object makes also a validation about the action, and deny it if it's not possible. Here you just need to interact with an external service to verify it.

The external service is just an interface in the domain layer, that you're going to implement with a concrete class into the infrastructure layer. Hence you will not have a directly binding with azure, but a service, let's say CloudService, that in it's implementation uses Azure. This allows you to build domain related exceptions that are thrown by classes that stay in the infrastructure layer.

Also the CQRS approach is valid. But you have to take care when you use it.

You can, for example, start a saga where you ask to the external service to create the instance (CreateRedisInstance), then, according to the event that you get (success or failure) you proceed with the next handler. But you really have to take care about middle situations: what should be done to handle failures between the 2 actions? You need also a rollback of the first action if the second one ends with a failure.

Said this, I would go with the first one if there're no really need to handle a complex process. Moreover, it looks that is all related to the same domain (no infra-domain actions are required), hence there're no real need to augment the complexity with a saga where every success/fail status should be correctly handled.

Upvotes: 1

Related Questions