In event sourcing, is it ok to introduce a dependency in my message class?

Question

Following Martin Fowler's explanation on event sourcing, I have a message class that looks something like this:

ShippingEvent
{
    Process(Ship ship) {}
}

However, in my case, I need to talk to another component in the Process method. More specific, I need to access a repository to get some basic data. Is it ok to add this repository to the method, i.e.:

ShippingEvent
{
    Process(Ship ship, IBasicDataRepository repo) {}
}

I could put it in the constructor of my message too, of course. However, I can't pass in the basic data, because the repo will be called multiple times with different parameters, depending on what's in the ´ship´ object.

So is it ok to introduce external dependencies in the event/message class or is there a better way?

Answer 1

I think that whatever is listening to your event should have a dependency on a repository, as opposed to having that dependency inside of your message.

Your message might be used in different contexts and an additional repository might not be needed every single time.

I would suggest keeping events as simple as possible. My events normally transfer a data structure. A listener then picks up an event and does something with that data structure.

You can implement IShippingEventProcessor - this would have a dependency on the IBasicDataRepository.

Finally, events normally promote loose coupling. A single event might be published and then picked up by a range of domains. It might be the case that one of the domains should know nothing about the IBasicDataRepository dependency.