Comments

edited

Hi everyone,

we use state-based aggregates in our application.

We encountered that we have to use String for the aggregate identifier. Otherwise an exception occurs while sending a command to the aggregate by annotating the id field with @TargetAggregateIdentifier. In this example I tried to use a java.util.UUID:

While researching I stumbled upon org.axonframework.modelling.command.GenericJpaRepository.Builder.identifierConverter(Function<String, ?>)

But there are two major problems:

I use Spring Boot and the GenericJpaRepositories are built in org.axonframework.spring.config.SpringAxonAutoConfigurer.registerAggregateBeanDefinitions(Configurer, BeanDefinitionRegistry) which cannot be customized easily. I have to override (nearly) the whole class to adjust the behaviour. Anyway, by doing this and setting .identifierConverter(UUID::fromString) the command can be handled.

The solution only works if I use a type which's toString() result can be reverted back to the type (like UUID.fromString(String) does). In practice I don't want to use a UUID as id but a value object like CustomerId which wraps a UUID. Having this I do not see any chance to annotate it with @AggregateIdentifier and to use it in a state-based aggregate.

As stated in #484 you also prefer the usage of value objects, but unfortunately I do not find a way to do this. Maybe it's a lack of documentation, but I fear it's a missing feature. That's the reason why I decided to create this issue.

This comment has been minimized.

Hi @OLibutzki, I think I can alleviate the two major problems you've noted here:

When you're using the Spring configuration of Axon, you will thus also be using the @Aggregate annotation I'd assume. The @Aggregate annotation has a field repository of type String. If you fill in the name of the repository you'd want to use for that Aggregate instance, it'll be wired upon start up. Thus, you should be able to create your GenericJpaRepository through it's Builder and provide the identifierConverter you wish.

In practice, I'd assume the 'typed ID'/value object you'd use as the Aggregate Identifier would always have a to string format. From that point, I do not see why it would be to big a problem to have a fromString function as well. When I am leveraging typed ID's for Aggregate/Entities, more often that class contains a UUID any how (which as we now, has a fromString function.

Concluding, I think point 1 is luckily covered by the framework.
I trust in you that this wasn't clear from the Reference Guide; I can assure you we're consistently looking to improve the guide. It sounds like the Spring configuration is one of those areas which still needs some improvement.

Point 2 is something I to be honest do not view as to big of a struggle. If my assumptions on your question were incorrect in this area, please tell me so.

If you're however okay with the above given answer, I think we can close this issue of for now. :-)