Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

How do you stay backward compatible with event-sourcing? Let say you release a version that has one kind of event, let call it X. You know how to handle that event in all the systems that extracts the events from the event source. In a later release you make a change to event X or delete it, how do you stay backward compatible with that?

To have a fully functional system you need to be able to handle the old event as the same time as you need to handle the updated version. Or if you delete that event type, then you will be stuck with code that is only there to handle legacy events which in my head can be a little bit messy in the long run.

share|improve this question
    
Take a look at the revisions on your first question... Stuff like Second question today about event-sourcing since I really think that it is an interesting topic that I would like to try out. are pure noise, they have nothing to do with the question itself. And please try to break your questions into sensible paragraphs to make them a little bit more readable. –  Yannis Rizos Nov 28 '11 at 8:42
add comment

2 Answers

up vote 3 down vote accepted

IMHO there's no such thing as really changing an event - if that happens you've really created a new event type. Once an event has happened in production, it's happened.

The cleanest way to handle this is to version your events and have an 'event upgrader' somewhere in your pipeline before the events get applied - we do it just after the events are deserialised. That way your application only needs to know about the latest version of the events. The upgrader can translate any changed attributes, remove unused ones or apply sensible defaults if you add any.

share|improve this answer
add comment

This is the reason for a decoupled system. Contracts should exist via an interface with consumable systems both internally and externally.

If the system is propagating a new event, then the code should be adjusted accordingly to consume the new event if need be. If the old event is being wrapped in an argument type, the handler should operate as it did before unless you have introduced new properties within the argument which would force the need to make an adjustment within the handler anyways.

You can only prepare to a given degree before you are preparing for something that may not come and the time wasted could have been spent better elsewhere.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.