Injecting dependencies into ReadModels

[Yaevh]

When a domain event is emitted, the readmodel may need to update itself using not only the data in the domain event itself, but also some additional data coming from an external service.
To use a specific example, some of my domain events contain a UserId pointing to the user that caused the event to happen. In that case I want to also persist the user email and full name in the readmodel; thus while updating the readmodel I need to query some UserDataProvider.

Currently the IReadModelContext.Resolver can be used to resolve such services, but this smells of service locator anti-pattern. It is also theoretically possible to build your own ReadModelStore that would support injecting dependencies into readmodels via constructor, but this both requires plenty of work, and constructor injection into entities doesn't seem like a good idea to me, especially since it's basically prohibited in most popular ORMs, including the ones supported by EventFlow (Entity Framework, Dapper etc.).

The solution that comes to my mind would be to introduce a new interface, IAmReadModelFor<TAggregate, TIdentity, TEvent, TDependency>:

public interface IAmReadModelFor<TAggregate, TIdentity, TEvent, TDependency>
{
    Task ApplyAsync(
        IReadModelContext context,
        IDomainEvent<TAggregate, TIdentity, TEvent> domainEvent,
        TDependency dependency,
        CancellationToken cancellationToken);
}

In this solution, ReadModelDomainEventApplier could use IResolver to resolve the TDependency and inject it into the readmodel, which would thus conform to recommended dependency injection rules.

What do you think of this idea? I can try to implement it, if my time and abilities permit it.

related to #373

[rasmus]

@Yaevh can you use a custom implementation of IReadModelFactory<>?

[hvidgaard-ims]

You are correct that the current way of resolving a dependency in a readmodel, is a service locator pattern. Whether or not that is an anti pattern is a discussion for another time, but I would add that if you do use a DI framework that actually verify your dependency graph at startup, such as SimpelInjector, it's impossible for it to verify this particular use of DI.

Your proposed solution does not solve the underlying issue that the dependency graph cannot be verified by the container, it have to be implemented in EventFlow which is less than ideal. I'm not sure I personally find it better than using a service locator in this particular case.

The problem exists because of how the IAmReadyModelFor interface is used on the actual POCO representing the underlying data. I think a better solution is having a "mutator" (for the lack of a better name) instead where dependencies can be handled by the container through constructor injection. Something quick from the top of my head:

public interface IReadModelMutator { } // tagging interface

And then implementing it like this

public class MyMutator : IReadModelMutator , IAmAsyncReadModelFor<TAggregate, TIdentity, TEvent, TReadModel >
{
    public MyMutator(MyDependency dep) {
        // dependency is injected upon creation
    }

    public Task ApplyAsync(
        IReadModelContext context,
        IDomainEvent<TAggregate, TIdentity, TEvent> domainEvent,
        TReadModel readModel
        CancellationToken cancellationToken) {
        ...
    }
}

[hvidgaard-ims]

@rasmus That is a good solution too, and possible right now, I was not aware of that particular abstraction.