Non-primitive types in events
When working with events, people usually accept examples of very simple value objects, consisting only of primitives. But what about when I need more information. Is it possible to create a specific framework 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 does not have any complex logic or anything else.
but if i had another event:
public class RedTrainCleaned
{
Datetime start
Datetime end
Carriage[] Carriages
}
The move will also be part of the second event interface. If you allowed 40 or 50 events with the same "event value object", this means that my project will be strongly associated with this object. It doesn't look that good to me, but what can I do to avoid it? Is this a warning that something in my domain analysis is not well done?
thank you for your help,
source to share
I guess it depends on how the default Carriage
is in your domain. If it changes for one event, should it change for others?
I think I am thinking of an example Address
. This is pretty standard within a domain, and I think it makes sense to include this in my event object if I raise an event containing address information. That way, if it becomes known that we need to have a ZIP + 4 extension for my zip code, I can add a new field to my class Address
and have this property for future events. I can make changes in one place and make it available for future events.
If it Carriage
might mean something different in different events, then it might not be something you should include - and instead flatten it out in your case. But if there Carriage
really is a ubiquitous definition in your domain, I think it's okay to include it in your event classes.
As unpleasant as it can be to hear, I think it really "depends".
Hope this helps. Good luck!
source to share
You can create a separate class library project to contain message classes (DTOs). This project should ideally be independent of other solution projects and should only contain serializable POCOs. There will be minimal dependency in this case as you only need to share the DTO library.
source to share