域服务注入域实体

Question

我正在学习领域驱动设计，但我对实体和向其中注入领域服务感到有些困惑。我发现了这个blog，结论是向实体注入服务是个坏主意。我部分同意这一点，但在这种情况下该怎么做： 我有用户实体，它是一个聚合根，其中有密码值对象。它看起来像这样：

密码值对象：

public class Password  
{  
    public string Hash { get; private set; }

    public string Salt { get; private set; }

    private readonly IHashGeneratorService _hashGeneratorService;

    public Password(IHashGeneratorService hashGeneratorService)
    {
        _hashGeneratorService = hashGeneratorService;
    }

    public void GenerateHash(string inputString)
    {
        //Some logic

        Salt = hashGeneratorService.GenerateSalt();
        Hash = hashGeneratorService.GenerateHash(inputString);
    }
}

用户实体：

public class User
{
    public Password Password { get; private set; }

    public User(IHashGeneratorService hashGeneratorService)
    {
        this.Password = new Password(hashGeneratorService);
    }
}

在这种情况下，如果我通过工厂创建用户实体，我需要向工厂构造函数或 Create() 方法提供 IHashGeneratorService 实现。之后，如果我的工厂被使用，例如。 SomeUserService 我必须为其提供实现（例如，通过 ctor 注入）。等等... 老实说，我闻起来很香，因为我的很多类都依赖于哈希生成器服务实现，但只有 Password 类使用它。而且它也违反了我假设的 Password 类的 SRP 原则。

我找到了一些解决方案：

1. 使用服务定位器。但它也有异味，因为它是一种反模式，如果我们使用它，就很难测试和管理实体。

2. 直接在密码方法中实现散列算法。

3. 坚持我所拥有的 :) 上面提到了缺点，优点是我的类更容易测试，因为我可以提供模拟服务而不是完整实现。

我个人倾向于将我的代码重构为第二种解决方案，因为它不会破坏 SRP（或者它会破坏？:)），类不依赖于哈希服务实现。还有什么？ 或者您有其他解决方案吗？

Answer 1

我对 DDD 很陌生，但是我相信散列密码不是域的问题，而是技术问题，就像持久性一样。哈希服务应该在 domain 中定义它的接口，但它的实现是在 infrastructure 层中。 应用程序服务然后会使用 hash service 对密码进行哈希处理并在之前创建一个Password 实例（应该是一个值对象）将其传递给 User 聚合根。

在某些情况下，聚合必须使用服务，例如依赖解决方案非常复杂且特定于域时。在这种情况下，应用程序服务可以将域服务传递给聚合方法。然后聚合将双重分派到服务以解析引用。

有关更多信息，您可以阅读由 Vaughn Vernon 撰写的实施领域驱动设计一书。他在第 362 页（模型导航）中谈到了这一点，而且在本书的其他几个地方也谈到了这一点。

Answer 2

不知道为什么，为什么只考虑注入构造函数参数。 AFAIK，DI 容器注入属性或字段是一个常见功能。例如，使用 MEF，您可以编写如下内容：

class SomeUserService : ISomeUserService
{
    [Import]
    private IHashGeneratorService hashGeneratorService { get; set; }

    // ...
}

并仅在您真正需要的那些类型中注入依赖项。