views:

130

answers:

1

Versioning
If your events changes you would create a new version of that event, and keep the old ones. To keep your domain code form being bloated with handling of all versions of events you would basically introduce a component that converts your events from previous to newer versions, and then apply them on the domain. Remember that events are things that actually happened in your domain so in most cases the information in deprecated events are valuable.

I still haven't found any example of this.

Any help?

+2  A: 

There are two main ways to handle event conversions. Both happen during event deserialization :

  1. You can add new classes with version numbers (SomethingHappened, SomethingHappened2, SomethingHappened3). The deserializer will instanciate and populate the class, the pass it to a converter to get the same event in its higher version, here SomethingHappened3. One of the problem is that you'll have to update also event handlers to use the last version of the event. To mitigate this, you can use a convention that SomethingHappened is always the last version. When going to v2, rename SomethingHappened as SomethingHappened1 and create a SomethingHappened that will be the v2. To do that you need to have control on the classes created from serialized event since the serialized class name will not contain the version number, you should store it aside.

  2. Instead keeping every version of the classes in your code, the converter will receive a Document (a tree, like an Xml document or JSon object) and will modify it to provide information needed to build the last version.

All this depends on the control you have on your deserialization pipeline.

Think Before Coding
Makes sense. Would be cool to see some sample code. Is there anything?
Arnis L.