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?
), 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.