search

vudodov / my-website-comments

0 stars 0 forks source link

posts/event-sourcing/events-versioning/ #6

Open utterances-bot opened 6 months ago

utterances-bot commented 6 months ago

Event Sourcing: Events Evolution, Versioning, and Migration – Val's Tech Blog

Systems do evolve and unavoidably evolution leads to breaking changes... If you are doing event sourcing, events evolution is unavoidable, ultimately you will crash 🔥🚒 into it. The more you know, the better you prepared, as they say 🤓

http://valerii-udodov.com/posts/event-sourcing/events-versioning/

paulfrench commented 6 months ago

Nice post. Not so sure on a few areas. In my eyes you can have many consumers consuming events from the event source. You have no idea what data they may use or rely on. Hence if an event loses data in it's payload that to me is a breaking change.

I think we should follow a semver,org approach. The version of the event depends on the previous event structure. A consumer might be processing an event with version 1.2.5, it will happily continue processing this event up to 1.X.Y where X and Y go as high as you like. As X increases you are introducing new payload (consumers can ignore new content), if Y goes up it could be a simple bug fix .

If we have major a change in the version (i.e. the latest version of the event is not backwards compatible with the previous version) then consumers will be forced to re-checked and modified if required.

I'm new to event sourcing so interested in what people think

mcrio commented 2 months ago

@paulfrench you are mixing up integration events, domain events, event sourced events. There is just one consumer application to the event stream that builds up the aggregate state by applying those events. That application also produces new events, and has all the knowledge about different versions. You are probably referring to integration events for propagating events between different bounded contexts.