Events serialization and good practice

Hi all,

I’ve got a question that is mostly related to good/bad practices and to try to pick your brains with a dilemma.

Should an event contain abstract/interface properties that could have different values?


public class SomethingHappened {

public Guid AggregateId { get; set; }

public IChannel Channel { get; set; }


public class ChannelA : IChannel {

public string Name { get; set; }


public class ChannelB : IChannel {

public string Name { get; set; }

public DateTime Timestamp { get; set; }


If this is allowed (normal practice) I could face a problem when retrieving the event from event store and being unable to deserialize it because the deserializator does not know the specific class that should be instantiated (ChannelB or ChannelA).

Of course I could add some logic to store for example the type of the specific IChannel used, keep it in metadata, and use it to instruct the deserializator which one to pick.

My question is double: is it a good/allowed practice to use domain events with abstract properties or better to avoid it?

And next: does EventStore handle this out of the box like for example other databases such as MongoDb that store some _t value with the Type or the equivalent would be to manually store the type as metadata?


PS: With my current implementation I allow events with abstract properties and I have some serializer/deserializer loaded at runtime depending on the event type, which is stored as metadata, but it’s something that complicates things a bit since it uses reflection and I wonder whether I should have aimed for out of the box serializable events instead.

Interfaces are generally about behavior, not data. What does it mean to serialize your behavior on the wire? If you need two different shapes of data in your event, you might have two different events. If you don’t have two different events, you can use a nested json object (i.e. a choice) like
// ThingHappened
“ChannelA”: undefined,
“ChannelB”: { … }