Axon CQRS & EventSourcing deep validation in the db

Question

I am migrating and existing crud application into Axon, and I have some concerns with the following scenario. I have an api given below to create groups,

 @PostMapping
public Mono<IdDto> createGroup(@RequestBody @Valid CreateGroupCommand command) {
    log.trace("Create GroupResponseInfoDto request {}", command);
    return commandGateway.send(command)
            .map((o) -> new IdDto((UUID) o));
}

The command looks like,

   @Data
public class CreateGroupCommand {

    @NotBlank
    private String name;

    @NotBlank
    private String description;
}

and the main requirement here is that the group name must be unique. Therefore, in the Aggregate I have the following code to check this logic.

  @CommandHandler
public GroupAggregate(CreateGroupCommand command, GroupRepository groupRepository, ModelMapper mapper) {
    log.trace("Handle create group command {}", command);
    groupRepository.findByName(command.getName())
            .ifPresent((g) -> {
                throw new ApplicationException(UserMsError.GROUP_ALREADY_EXISTS.name());
            });
    GroupCreatedEvent event = mapper.map(command, GroupCreatedEvent.class);
    event.setId(UUID.randomUUID());
    AggregateLifecycle.apply(event);
}

And once the validation pareses, the event is persisted by a projector into the db.

@EventSourcingHandler
public void on(GroupCreatedEvent event) {
    log.trace("Group create event {}", event);
    groupRepository.findByName(event.getName())
            .ifPresent((g) -> {
                throw new ApplicationException(UserMsError.GROUP_ALREADY_EXISTS.name());
            });
    Group group = modelMapper.map(event, Group.class);
    groupRepository.save(group);
}

The problem now is, there is some lap time between the command execution and the persistance of the event results into group table. If another user creates a group in that time, the command does not fail as the record does not exist in the db. Now, I see in Axon site there is a way to create a temporary table where we put the command execution into some temporary table which we can use for validation purpose, but that requires additional coding and quite extra effort for each such requirement. It also means, if we persist the details on command execution, and for some reason the process fails then the record will exist in our validation table but not on the system. If we try to validate the scenario on event execution, that extra effort might not be required but in this case the problem is I am not able to fail the API call so that the user knows the results. Could you please recommend if there is an alternative approach to validate the input without an intermediate check?

Answer 1

The problem you are looking at is set-based validation. Whenever you're dealing with CQRS, it's the sets that will require extra work to be validated.

Although uncertain, I assume you're talking about the Set-Based Consistency Validation blog? That is, for a reason, the suggested approach to deal with set validation. Note that the implementation used in the blog can be found here.

Added, it quite recently has seen an update that does not include the problem you describe as follows:

It also means, if we persist the details on command execution, and for some reason, the process fails, then the record will exist in our validation table but not on the system.

Axon's transaction logic, supported through the UnitOfWork, will roll back the entire transaction if something fails. This thus anything you'd do inside the UnitOfWork, including updates to another table for validation.

I get that it's some boilerplate code, but it is the predicament of having the uniqueness requirement on a set. What might be something you can look into is forcing the uniqueness through the Aggregate Identifier. Axon's Event Store logic ensures no two events are using the same aggregate identifier. So, if you try to input a new aggregate (hence a new event) for an already existing aggregate identifier, the operation will fail. This approach is typically not feasible whenever the set-based consistency validation issue is described, though, so I am guessing it won't help you out.

Concluding, I'd take your win from the shared repository on the blog to minimize your personal effort on the matter.