没有服务定位器的域事件

Question

Giving the default implementation of Domain Events:

Interface that represents an domain event:

public interface IDomainEvent { }

Interface that represents a generic domain event handler:

public interface IEventHandler<T> where T : IDomainEvent

Central access point to raise new events:

public static class DomainEvents
{
    public static void Raise<T>(T event) where T : IDomainEvent
    {
        //Factory is a IoC container like Ninject. (Service Location/Bad thing)
        var eventHandlers = Factory.GetAll<IEventHandler<T>>();

        foreach (var handler in eventHandlers )
        {
            handler.Handle(event);
        }
    }
}

Consuming:

public class SaleCanceled : IDomainEvent
{
    private readonly Sale sale;

    public SaleCanceled(Sale sale)
    {
        this.sale = sale;
    }

    public Sale Sale
    {
        get{ return sale; }
    }
}

Service that raises the event:

public class SalesService
{
     public void CancelSale(int saleId)
     {
          // do cancel operation

          // creates an instance of SaleCanceled event

          // raises the event
          DomainEvents.Raise(instanceOfSaleCanceledEvent);
     } 
}

Is there another approach to use Domain Events without use of Service Location anti-pattern?

Answer 1

I guess in your case you really do not have to. Using dependency injection you could inject a IDomainEventDispatcher implementation into your service.

The reason why I think a singleton like this has made it into the mainstream it was one of the first implementations to be proposed by some prominent developers and at first it doesn't feel too wrong. The other reason is that events may need to be raised from within the domain:

public class Customer
{
    public void Enable()
    {
        _enabled = true;

        DomainEvents.Raise(new CustomerEnabledEvent(_id));
    }
}

At some stage I came across this post by Jan Kronquist: http://www.jayway.com/2013/06/20/dont-publish-domain-events-return-them/

This is the third time I have added that link to my answers since I have to give credit to this for changing my thinking. However, I think I'll stop doing that now. Sorry Jan :)

So the point is that we can change our implementation to the following:

public class Customer
{
    public CustomerEnabledEvent Enable()
    {
        _enabled = true;

        return new CustomerEnabledEvent(_id);
    }
}

Now our service can be changed to use an injected dispatcher:

public class CustomerService
{
    private IDomainEventDispatch _dispatcher;
    private ICustomerRepository _customerRepository;

    public CustomerService(ICustomerRepository customerRepository, IDomainEventDispatch dispatcher)
    {
        _customerRepository = customerRepository;
        _dispatcher = dispatcher;
    }

    public void Enable(Guid customerId)
    {
        _dispatcher.Raise(_customerRepository.Get(customerId).Enable());
    }
}

So no singleton is required and you can happily inject the dependency.

Answer 2

I have never used a static DomainPublisher and I have other arguments than @Eben on how I handle it. This is just my personal experience and here are some of the reasons that I want to share :

• because aggregate root produce events and the rule of thumb is that you should not inject anything inside your entitites, when you use injectable Domain Publisher you have to either introduce a domain service to invoke domain logic on the aggregate and raise an event with the Domain Publisher, either you handle it like explained by @Eben in the application service or you break the rule of thumb and you make your entitites injectable.
• if you chose to use a domain services when not needed, just for injecting a domain publisher makes your code more cluttered. The business intent is less obvious and it adds more objects to manage and their dependencies than needed.

What I do, is to have a collection of events to publish on the aggregate root entity. Each time an event should be published, it is just added to the collection. I inject the domain publisher into the aggregate root repository. Thus publishing of events can be handled at the infrastructure level by the domain publisher in the repository. Because a domain publisher implementation very often has to deal with middleware like queues and buses, infrastructure level is right place to handle it correctly IMO. You can more easily deal with strategies of how you deal with publishing events when for example there is an exception when saving your entity to the database. What you would not want is to publish events and not save entitites in your database or the other way round.

Answer 3

If you create class EventHandlerFactory with generic method Create<T> and T is constrained by IEventHandler<T> type, then this class will not service locator, but factory, because you create only IEventHandler<T> instances. At the same time Service locator is like God Object , he know everything.

More about this here