3

To prevent reinventing the wheel, I'd like to use MediatR in the Aggregates to publish domain events. (Un)Fortunately(?) MediatR works as a dependency that is injected into the classes, and not something that I can call statically. Therefore I'd end up creating a direct dependency on the library via the constructor.

I don't remember where I read it (and if I read it right), that I should avoid non-business dependencies in the constructors of the Aggregates.

Therefore, I shouldn't do something like this:

public class MyAggregate
{
    private readonly IMediator _mediator;
    public MyAggregate(IMediator mediator)
    {
        _mediator = mediator;
    }
}

That made me think deeply whether it was possible or recommended (Or not recommended) to use MediatR in the Aggregates...

Is there a way for me to use MediatR statically or should I implement my own Event Dispatcher?

P.S: Also, feel free to correct me if my understanding of the Aggregates dependencies are wrong.

P.S x2: I've searched Google and SO and can't find an answer to this. https://stackoverflow.com/search?q=mediatr+domain+events How to decouple MediatR from my business layer DDD: Referencing MediatR interface from the domain project

Jose A
  • 10,053
  • 11
  • 75
  • 108

1 Answers1

4

I should avoid non-business dependencies in the constructors of the Aggregates.

Not only in constructors; your business layer should not have dependencies to non-business in any form; even static.

What I do is just return the domain event from the aggregate to the application layer and then publish the domain event.

Please read these couple of post to better understand what I mean:

Don't publish Domain Events, return them! DDD-Application-Services-Explained

jlvaquero
  • 8,571
  • 1
  • 29
  • 45
  • 1
    I'm loving this! There are so many advantages to the method. This completely solves my problem! The only downside I see is that we need to pay attention to dispatch the events, which is trivial. – Jose A Jan 22 '19 at 19:20
  • 1
    The advantages that I see: 1) You have no external dependencies, hence the aggregate becomes easier by a much higher order of magnitude to unit test. 2) You have full control on when to dispatch the events.This soooo important, as I was about to implement a stateful custom dispatcher (Going after Jimmy's and Udi Dahan posts about better Domain Events) that could dispatch the events accordingly. – Jose A Jan 22 '19 at 19:26
  • 1
    With this I also solve the problem of transactions. I'm currently using MongoDB, and right after the aggregate has been inserted, I can just dispatch the events for other bounded context to react to the event. MediatR can now resolve all of the dependencies without issues. I'll be using it as a Saga as well! (Projects are on the same tier) Awesome! – Jose A Jan 22 '19 at 19:27
  • 1
    @JoseA If you can read spanish I also wanna point you to my blog where you can see how I model inmutable aggregates completely indepedient of persistence in all ways (schema and conceptual) that helps to avoid a lot of headaches: http://altplusf13.blogspot.com/2018/12/los-agregados-no-son-elementos.html http://altplusf13.blogspot.com/2018/12/the-big-idea-is-messaging.html – jlvaquero Jan 23 '19 at 08:36
  • Awesome! I'll give it a shot :) Thanks – Jose A Jan 23 '19 at 08:38
  • 1
    I just went over them. I liked the following 2 key pieces of information: #1) Just load aggregates with the information needed, not more. #2) Return events or some sort of differing mechanism that show you what changed instead of mutating the object itself. I like the idea of immutability and this is something I will take into consideration. Fortunately, I'm using MongoDB which makes handling data easier than traditional SQL – Jose A Jan 23 '19 at 08:52