When dealing with events, people are usually taking examples of very simple values object composed only of primitives.
But what about an event where i would need more information. Is is allowed to create specific structure to handle these cases ?
namespace Events {
public class BlueTrainCleaned
{
Datetime start
Datetime end
Carriage[] Carriages
}
public class Carriage
{
string Descrizione
int Quantity
}
}
The Carriage class is part of the event namespace and has not any complex logic or anything.
but if I had another event :
public class RedTrainCleaned
{
Datetime start
Datetime end
Carriage[] Carriages
}
Carriage will be part of the interface of the second event also. If have let’s say 40 or 50 event with the same “event value object”, that means that my project will be heavily coupled on this object. It does not look so good to me, but what could I do to avoid this? Is it a warning that something in the analysis of my domain is not well done?
thanks for your help,
I guess it depends on how standard
Carriageis in your domain. If it changes for one event, should it change for the other ones, too?I guess I think of the example of
Address. It’s pretty standard within a domain, and I think it makes sense to include that in my event object if I am raising an event that contains address information. This way, if it becomes known that we need to have a ZIP+4 extension to my zip code, I can add a new field to myAddressclass and have that property available for future events. I can make the change in a single place and have it available for future events.If
Carriagecould mean something different across different events, then maybe it’s not something you should include – and instead, flatten it out in your event. But ifCarriagereally is an ubiquitous definition within your domain, then I think it’s fine to include it in your event classes.As much as it may be frustrating to hear, I think it really “depends”.
I hope this helps. Good luck!!