DDDD: Double Dispatch

I just finished watching David Laribee's devTeach video. Towards the middle of the presentation he started talking about domain services and how we can use double dispatching to provide a service to a domain entity. By doing this, we gain the ability for the domain object to call the domain service—without injecting it during construction. This, in turn, facilitates variability because we can provide different implementations of the service which may or may not access other external services or state—all without leaking infrastructure concepts into the domain.

Using double dispatch works great in traditional DDD, where you simply pass the domain service to the entity as part of a call to a method perform some computation. But what about DDDD?

In typical DDDD, we have a MapMessageToAggregateRootHandler that loads the aggregate, casts it to IConsume (T is a Message) and passes the message into the aggregate for handling. This doesn't work with double dispatch.

The only other possibility that I can see, which still avoids injection, is to create different message handlers for those messages that require double dispatch capabilities and to and expose domain-specific methods on the aggregate root rather than a generic Consume method. Then the handler could call the method, provide the message and corresponding domain service—or it could simply provide the needed parameters from the message along with the service.

UPDATE: There is another option. The aggregate root could explicitly implement an interface like IConsume. Then we could have another application service that maps a specific message along with a domain service to the aggregate root retrieved from a repository. The types of messages that require this new handler could all easily be registered in the DI configuration. Granted, I haven't fully analyzed the architectural implications of such an interface, but from an implementation perspective, it should work.