Instead of using the fully qualified class names as payload types for the messages, we could (for example) use a combination of context, aggregate type (if applicable), and simple name, as the default.
On top of that, it should become easier for users to define their own names for messages instead of relying on Axon Framework's default approach. This last pointer essentially mirrors the request made in #722.
Either way, not relying on the FQCN can have many benefits:
Easier interoperability with non-JVM languages
Data is more human-readable.
Enforces unique business names while still allowing different interpretations between aggregates.
Easier message target resolving.
It separates infrastructure (Java classes) from business (commands, events, and queries)
During the POC phase of Axon Framework, we played around with the concept of the so-called QualifiedName to be the replacement for using Class<?> payloadType throughout.
Description
Instead of using the fully qualified class names as payload types for the messages, we could (for example) use a combination of context, aggregate type (if applicable), and simple name, as the default. On top of that, it should become easier for users to define their own names for messages instead of relying on Axon Framework's default approach. This last pointer essentially mirrors the request made in #722.
Either way, not relying on the FQCN can have many benefits:
During the POC phase of Axon Framework, we played around with the concept of the so-called
QualifiedNameto be the replacement for usingClass<?> payloadTypethroughout.Examples:
io.axoniq.hotel.api.booking.AddRoomToInventoryEvent- >booking.Room.AddRoomToInventoryEventio.axoniq.hotel.api.inventory.AddRoomToInventoryEvent- >inventory.Room.AddRoomToInventoryEventWhen picking up this issue, be sure to check for any pending TODOs referring to the issue number of this issue.