域驱动设计中 IoC 自动接线的选项

Question

在我最新的 ASP.NET MVC 2 应用程序中，我一直在尝试将域驱动的概念付诸实践设计 (DDD)、单一职责原则 (SRP)、控制反转 (IoC)，以及 < a href="http://en.wikipedia.org/wiki/Test_driven_development" rel="nofollow noreferrer">测试驱动开发 (TDD)。作为一个架构示例，我一直在关注 Jeffery Palermo 的“洋葱架构 ”，该内容在 ASP.NET MVC 2 实际操作 中得到了极大的扩展。

虽然我已经开始成功应用这些原则中的大部分（一些？），但我缺少一个关键部分谜题。我无法确定将服务层自动连接到我的域实体的最佳机制。

举个例子：每个需要发送电子邮件的域实体都应该依赖于 IEmailService 接口。根据我的阅读，揭示这种依赖性的最佳实践是使用构造函数注入。在我的 UI 层中，我使用 ASP.NET 中的 StructureMapControllerFactory 对存储库接口实现执行类似的注入MVC 贡献。

我感到困惑的是，将必要的服务自动连接到域实体中的最佳机制是什么？域实体是否应该以这种方式注入？如果我不将 IEmailService 注入域实体中，我将如何使用它？

其他 Stack Overflow 问题是很棒的 DDD、SRP、IoC、TDD 参考：

• IoC 容器和域驱动设计
• 如何通过领域驱动设计避免出现非常大的对象

Answer 1

除非我误解了您的意图，而是选择专注于语义，否则我将剖析此声明“作为示例：每个需要发送电子邮件的能力的域实体都应该依赖于 IEmailService 接口。”

我不得不说这本身就是 DDD 的极端混蛋。为什么域实体需要依赖电子邮件服务？国际海事组织不应该。这是没有道理的。

然而，与域实体结合的业务操作需要发送电子邮件。您应该将 IEmailService 依赖项包含在此类中，而不是域实体中。这个类很可能属于几个几乎同义的名称之一：模型、服务或控制器，具体取决于您所在的架构/层。

此时，您的 StructureMapControllerFactory 将正确地自动连接所有需要的内容。将使用 IEmailService。

虽然我可能有点过度概括，但让域实体成为 POCO 或接近 POCO（以避免违反 SRP）几乎是标准做法，但是为了序列化和验证，域实体中经常会违反 SRP。选择违反 SRP 来解决这些类型的交叉问题更多的是个人信仰立场，而不是“正确”或“错误”的决定。

作为最后的跟进，如果您的问题是真正在独立服务中运行的代码部分（无论是基于 Web 还是基于操作系统）以及如何连接依赖项，则正常的解决方案是在基础上接管服务level 并以与 MVC 中的 StructureMapControllerFactory 相同的类似方式对其应用 IOC。如何实现这一点完全取决于您正在使用的基础设施。

响应：

假设您有 IOrderConfirmService，它有一个方法 EmailOrderConfirmation(Order order)。您最终会得到这样的结果：

public class MyOrderConfirmService : IOrderConfirmService
{    
    private readonly IEmailService _mailer;

    public MyOrderConfirmService(IEmailService mailer)
    {        
        _mailer = mailer;        
    }

    public void EmailOrderConfirmation(Order order)
    {        
        var msg = ConvertOrderToMessage(order); //good extension method candidite
        _mailer.Send(msg);        
    }    
}

您将拥有 OrderController 类，该类类似于

public class OrderController : Controller
{    
    private readonly IOrderConfirmService _service;

    public OrderController(IOrderConfirmService service)
    {        
        _service= service;        
    }

    public ActionResult Confirm()
    {      
            _service.EmailOrderConfirmation(some order);

            return View();
    }    
}

StrucutreMap，当您正确使用构造函数注入时，它将固有地构建您的整个架构链。这是紧耦合和控制反转之间的根本区别。因此，当 StructureMapFactory 构建控制器时，它首先看到的是它需要 IOrderConfirmService。此时它将检查是否可以直接插入 IOrderConfirmService，但它不能，因为它需要 IEmailService。因此它会检查是否可以插入 IEmailService，出于争论起见，我们可以说它可以。因此，此时它将构建 EmailService，然后构建 MyOrderConfirmService 并插入 EmailService，最后构建 OrderController 并插入 MyOrderConfirmService。这就是术语“控制反转”的由来。 StructureMap 将在整个依赖链中首先构建 EmailService，最后构建 Controller。在紧密耦合的设置中，这将与首先构建控制器并且必须构建业务服务然后构建电子邮件服务相反。与 IOC 相比，紧耦合设计非常脆弱。