通过在领域模型中使用 IoC 来打破“无处不在的语言”？

Question

我的问题是关于 Udi's solution 到域事件，特别是 DomainEvents 类（见下面的代码）

摘自 Udi 的代码。它以静态类的形式存在域模型。

public static class DomainEvents
{ 
   [ThreadStatic] //so that each thread has its own callbacks
   private static List<Delegate> actions;

   public static IContainer Container { get; set; } //as before

   //Registers a callback for the given domain event
   public static void Register<T>(Action<T> callback) where T : IDomainEvent
   {
      if (actions == null)
         actions = new List<Delegate>();

      actions.Add(callback);
  }

  //Clears callbacks passed to Register on the current thread
  public static void ClearCallbacks ()
  { 
      actions = null;
  }

  //Raises the given domain event
  public static void Raise<T>(T args) where T : IDomainEvent
  {
     if (Container != null)
        foreach(var handler in Container.ResolveAll<Handles<T>>())
           handler.Handle(args);

     if (actions != null)
         foreach (var action in actions)
             if (action is Action<T>)
                 ((Action<T>)action)(args);
  }
} 

从上面的代码中，静态成员IContainer 在域模型中创建了一个ioc-container-dependency。虽然我不确定 Udi 的 IContainer 是接口还是实际的 IoC 容器。

我在他的样本中没有看到类似的东西：

public interface IContainer
{
    IEnumerable<T> ResolveAll<T>();
}

我的第一个问题是：DomainEvents 类中的 IContainer 是什么？如果它真的是一个 IoC 容器，那么它不违反 “没有域中的基础设施”？ （如有错误请指正）

DDD 的想法不就是将基础架构与域分离吗？

我的第二个问题是：DomainEvents 本身是否违反规则“DDD 无处不在的语言”？因为它的实现不属于任何领域。

Answer 1

我同意，域必须不了解基础架构，并且在一定程度上，Udi 的解决方案提供了这种抽象。就个人而言，我更喜欢 Mark Seemann 在文章 cmets 中暗示的解决方案：通过接口注入事件聚合器。通过这种方式，事件作为一等域模型公民保持在那里，但通过最松散的耦合。