Hi Stephan,

I believe the architectural information is already a value on its own. If you can create a structural evaluation to find out what version of event is produced and what is consumed...

For Axon-based systems there is another solution possible. Axon Framework provides support of event upcasters, which is in essence reading the event from the event store and applying a modification on it before it gets deserialized into a instance of a Event class in Java. This is helpful for some changes introduced during the event evolution. For this purpose, Axon Framework supports a notion of event revision, with a corresponding event revision resolver helper... Axon Framework itself can work with different event revisions - their own implementation is based on the @Revision annotation.

In the same time, we are currently working on an Avro-Axon-Serializer, focusing on using Apache Avro as serialization format for Axon Events... We introduced a schema revision there and created our own revision resolver...

Cheers,

Simon

I would agree to @zambrovski that upcasting an event transparently is a better option than handle diffenrent event versions in separate event handlers. This could cause confusion...

The idea is, that reading events are usually two-fold: getting into you JVM process in serialized form and then run the deserialization...
If you follow the argumentation of Greg Young (I reference to his book (https://leanpub.com/esversioning), the upcasting should happen between these two steps, if you use typed-based events (so every event is represented by a class in a strongly-typed language).

Since it is very difficult to have two versions of the same class on the classpath in the same time, the approach is to get the event into a kind of an intermediate representation, change the content of the old event into content matching the structure of the new version of the event class and deserialize it then.

To give you an example for Apache Avro: a byte stream of Avro Single Object Encoded is written into a DB. It is first read out and transferred into a Generic Record format (it is a Map<String, Object>), then adjusted to match the target structure of the new event and then de-serialized into Specific Record Format - being a class generated from the Schema...

In Axon event of a former version would be upcasted to a new version as @zambrovski described. I think this is an elegant solution to reduce complexity of event versioning.