As per posts passim, an event is considered to be any class that implements the marker interface IEvent that does not force any properties or methods. (This is often considered an anti-pattern, but I think it is justified in this case as it helps the developer understand the role of the class in the system).
However, once a specific event class is stored in an event stream, I need to make sure it can be read back even if the event definition itself changes over the lifetime of the project. For instance, if I realise after the project has been in use for a while that there is an added property, I should record for an event or that something I had prototyped as an integer should really be a money field, then I will need to make sure that the event records stored before that change occurred can still be read.
The first step towards this is to have each event definition have an increment-only version number property. This version number is written (along with the event class name) in the context part of the event stream which means it can be used to help the serialiser reload the event data at a later point in time.
The specifics of this are achieved by adding serialisation methods to each event class, tagged with the OnSerializing, OnSerialized, OnDeserializing and OnDeserialized attributes. The code generation project now adds empty stubs for these methods whenever the code generation is performed from the CQRS model.
This allows any type conversions, or substitutions for missing values to take place when a newer version of an event is populated from an event stream record that was written by a previous version of that record.
CodeProject
Submit an article or tip
