Event Serialization

I’m reflecting on the need to do good up-front domain event design. Failure will likely lead to situations that require sweeping changes to both the semantics and structure of your events. Any such sweeping changes will be painful to accommodate in an event sourced system.

This got me to thinking about the need to make a good initial choice for the event serialization format. I came to this thought based on an assumption that it would be pretty disruptive (and painful) to change the format for an axon application that is in production. Is my assumption correct?

In the past I’ve heard Allard promote the use of the Jackson JSON serializer for events (and xstream for everything else). However, after yesterday (day 2 of axon workshop in Denver–which was fantastic!) I believe that maybe he’d recommend protobuf (Google’s Protocol Buffers) instead. I’m wondering if I should look into it. I guess my decision would be weighed heavily against how painful it is to switch serialization formats in an axon application in production, and secondarily how difficult is it to work with protobuf both in terms of integrating with Axon and any other client who will consume published events?

Hi Troy,

changing the serialization my be disruptive, although there are relatively easy ways to work with multiple formats. One way would be to write a serializer that peeks into the format and then delegates to one or the other (or perhaps based on type and revision).
However, thinking a bit upfront on the serialization format (and using a formal schema definition) is time well spent.

I have always been promoting JSON as serialization type, because of it’s interoperability and simple format. During the training in Denver (glad you liked it :wink: ), I did mention Google Protobuf as a potential alternative. It’s a binary format, and very compact, though still designed in such a way that it is backward and forward compatible when it comes to schema changes. That means a serializer won’t complain when an expected element isn’t available nor when an unknown element arrives.

If interoperability is a “thing” in your project, my first choice would (still) be JSON. It will allow for much simpler publication of events to third party applications.

Hope this helps.


Thanks Allard, that does help!