在 DDD 中将全局规则验证放在哪里

Question

我是 DDD 的新手，我正在尝试将它应用到现实生活中。没有关于此类验证逻辑的问题，如空检查、空字符串检查等 - 直接进入实体构造函数/属性。但是在哪里验证一些全局规则，比如“唯一用户名”？

所以，我们有实体用户

public class User : IAggregateRoot
{
   private string _name;

   public string Name
   {
      get { return _name; }
      set { _name = value; }
   }

   // other data and behavior
}

和用户存储库

public interface IUserRepository : IRepository<User>
{
   User FindByName(string name);
}

选项是：

1. 将存储库注入实体
2. 将存储库注入工厂
3. 在域服务上创建操作
4. ???

每个选项更详细：

1 .将存储库注入实体

我可以在实体构造函数/属性中查询存储库。但我认为在实体中保留对存储库的引用是一种不好的气味。

public User(IUserRepository repository)
{
    _repository = repository;
}

public string Name
{
    get { return _name; }
    set 
    {
       if (_repository.FindByName(value) != null)
          throw new UserAlreadyExistsException();

       _name = value; 
    }
}

更新：我们可以使用 DI 通过 Specification 对象隐藏 User 和 IUserRepository 之间的依赖关系。

2。将存储库注入工厂

我可以把这个验证逻辑放在 UserFactory 中。但是，如果我们想更改现有用户的名称怎么办？

3。在域服务上创建操作

我可以创建域服务来创建和编辑用户。但是有人可以直接编辑用户名而不调用该服务...

public class AdministrationService
{
    private IUserRepository _userRepository;

    public AdministrationService(IUserRepository userRepository)
    {
        _userRepository = userRepository;
    }

    public void RenameUser(string oldName, string newName)
    {
        if (_userRepository.FindByName(newName) != null)
            throw new UserAlreadyExistException();

        User user = _userRepository.FindByName(oldName);
        user.Name = newName;
        _userRepository.Save(user);
    }
}

4. ???

您将实体的全局验证逻辑放在哪里？

谢谢！

Answer 1

大多数时候最好将这些规则放在Specification 对象中。 您可以将这些Specifications 放在您的域包中，这样任何使用您的域包的人都可以访问它们。使用规范，您可以将您的业务规则与您的实体捆绑在一起，而不会创建难以阅读的实体以及对服务和存储库的不希望的依赖关系。如果需要，您可以将服务或存储库的依赖项注入到规范中。

根据上下文，您可以使用规范对象构建不同的验证器。

实体的主要关注点应该是跟踪业务状态——这已经足够了，他们不应该关心验证。

例子

public class User
{
    public string Id { get; set; }
    public string Name { get; set; }
}

两种规格：

public class IdNotEmptySpecification : ISpecification<User>
{
    public bool IsSatisfiedBy(User subject)
    {
        return !string.IsNullOrEmpty(subject.Id);
    }
}


public class NameNotTakenSpecification : ISpecification<User>
{
    // omitted code to set service; better use DI
    private Service.IUserNameService UserNameService { get; set; } 

    public bool IsSatisfiedBy(User subject)
    {
        return UserNameService.NameIsAvailable(subject.Name);
    }
}

还有一个验证器：

public class UserPersistenceValidator : IValidator<User>
{
    private readonly IList<ISpecification<User>> Rules =
        new List<ISpecification<User>>
            {
                new IdNotEmptySpecification(),
                new NameNotEmptySpecification(),
                new NameNotTakenSpecification()
                // and more ... better use DI to fill this list
            };

    public bool IsValid(User entity)
    {
        return BrokenRules(entity).Count() == 0;
    }

    public IEnumerable<string> BrokenRules(User entity)
    {
        return Rules.Where(rule => !rule.IsSatisfiedBy(entity))
                    .Select(rule => GetMessageForBrokenRule(rule));
    }

    // ...
}

为了完整性，接口：

public interface IValidator<T>
{
    bool IsValid(T entity);
    IEnumerable<string> BrokenRules(T entity);
}

public interface ISpecification<T>
{
    bool IsSatisfiedBy(T subject);
}

注意事项

我认为 Vijay Patel 早先的回答是朝着正确的方向，但我觉得有点不对劲。他建议用户实体取决于规范，我认为这应该是相反的。这样，您可以让规范依赖于服务、存储库和一般上下文，而无需通过规范依赖使您的实体依赖它们。

参考文献

一个很好回答的相关问题，例如：Validation in a Domain Driven Design。

Eric Evans 在chapter 9, pp 145 中描述了使用规范模式进行验证、选择和对象构造。

您可能会对这个article on the specification pattern 的 .Net 应用程序感兴趣。

Answer 2

如果是用户输入，我不建议禁止更改实体中的属性。 例如，如果验证没有通过，您仍然可以使用该实例将其与验证结果一起显示在用户界面中，以便用户更正错误。

Jimmy Nilsson 在他的“应用领域驱动设计和模式”中建议验证特定操作，而不仅仅是持久化。虽然实体可以成功持久化，但真正的验证发生在实体即将更改其状态时，例如“已订购”状态更改为“已购买”。

创建时，实例必须是有效保存，这涉及检查唯一性。它与有效订购不同，后者不仅必须检查唯一性，还必须检查客户的信誉和商店的可用性等。

因此，不应在属性分配上调用验证逻辑，而应在聚合级别操作上调用验证逻辑，无论它们是否持久。

Answer 3

编辑：从其他答案来看，这种“域服务”的正确名称是规范。我更新了我的答案以反映这一点，包括更详细的代码示例。

我会选择选项 3；创建一个 domain service 规范，该规范封装了执行验证的实际逻辑。例如，规范最初调用存储库，但您可以在稍后阶段将其替换为 Web 服务调用。拥有抽象规范背后的所有逻辑将使整体设计更加灵活。

为防止有人未经验证就编辑名称，请将规范作为编辑名称的必要方面。您可以通过将实体的 API 更改为以下内容来实现此目的：

public class User
{
    public string Name { get; private set; }

    public void SetName(string name, ISpecification<User, string> specification)
    {
        // Insert basic null validation here.

        if (!specification.IsSatisfiedBy(this, name))
        {
            // Throw some validation exception.
        }

        this.Name = name;
    }
}

public interface ISpecification<TType, TValue>
{
    bool IsSatisfiedBy(TType obj, TValue value);
}

public class UniqueUserNameSpecification : ISpecification<User, string>
{
    private IUserRepository repository;

    public UniqueUserNameSpecification(IUserRepository repository)
    {
        this.repository = repository;
    }

    public bool IsSatisfiedBy(User obj, string value)
    {
        if (value == obj.Name)
        {
            return true;
        }

        // Use this.repository for further validation of the name.
    }
}

您的调用代码如下所示：

var userRepository = IoC.Resolve<IUserRepository>();
var specification = new UniqueUserNameSpecification(userRepository);

user.SetName("John", specification);

当然，您可以在单元测试中模拟 ISpecification 以便于测试。

Answer 4

我会使用 规范 来封装规则。然后，您可以在 UserName 属性更新时调用（或从其他任何可能需要它的地方调用）：

public class UniqueUserNameSpecification : ISpecification
{
  public bool IsSatisifiedBy(User user)
  {
     // Check if the username is unique here
  }
}

public class User
{
   string _Name;
   UniqueUserNameSpecification _UniqueUserNameSpecification;  // You decide how this is injected 

   public string Name
   {
      get { return _Name; }
      set
      {
        if (_UniqueUserNameSpecification.IsSatisifiedBy(this))
        {
           _Name = value;
        }
        else
        {
           // Execute your custom warning here
        }
      }
   }
}

如果其他开发者尝试直接修改User.Name 也没关系，因为该规则将始终执行。

Find out more here

Answer 5

我不是 DDD 方面的专家，但我也问过自己同样的问题，这就是我想出的： 验证逻辑通常应该进入构造函数/工厂和设置器。这样您就可以保证您始终拥有有效的域对象。但是，如果验证涉及影响性能的数据库查询，那么有效的实施需要不同的设计。

(1) 注入实体： 注入实体在技术上可能很困难，而且由于数据库逻辑的碎片化，也使得管理应用程序性能变得非常困难。看似简单的操作现在可能会产生意想不到的性能影响。这也使得无法优化域对象以对相同类型实体的组进行操作，您不再可以编写单个组查询，而是始终对每个实体进行单独的查询。

(2) 注入存储库：您不应该将任何业务逻辑放在存储库中。使存储库保持简单和集中。它们应该像集合一样工作，并且只包含用于添加、删除和查找对象的逻辑（有些甚至将查找方法衍生到其他对象）。

(3) 域服务 这似乎是处理需要数据库查询的验证的最合乎逻辑的地方。一个好的实现将使构造函数/工厂和 setter 涉及包私有，以便只能使用域服务创建/修改实体。

Answer 6

在我的 CQRS 框架中，每个 Command Handler 类还包含一个 ValidateCommand 方法，然后该方法调用域中适当的业务/验证逻辑（主要实现为实体方法或实体静态方法）。

所以调用者会这样做：

if (cmdService.ValidateCommand(myCommand) == ValidationResult.OK)
{
    // Now we can assume there will be no business reason to reject
    // the command
    cmdService.ExecuteCommand(myCommand); // Async
}

每个专门的命令处理程序都包含包装逻辑，例如：

public ValidationResult ValidateCommand(MakeCustomerGold command)
{
    var result = new ValidationResult();
    if (Customer.CanMakeGold(command.CustomerId))
    {
        // "OK" logic here
    } else {
        // "Not OK" logic here
    }
}

然后，命令处理程序的 ExecuteCommand 方法将再次调用 ValidateCommand()，因此即使客户端没有打扰，域中也不会发生任何不应该发生的事情。

Answer 7

创建一个方法，例如，称为 IsUserNameValid() 并使其可以从任何地方访问。我会自己把它放在用户服务中。当未来发生变化时，这样做不会限制您。它将验证代码保存在一个地方（实现），如果验证发生变化，依赖它的其他代码不必更改您可能会发现以后需要从多个地方调用它，例如用于视觉指示的 ui无需求助于异常处理。用于正确操作的服务层，以及用于确保存储项有效的存储库（缓存、数据库等）层。

Answer 8

我喜欢选项 3。最简单的实现可能是这样的：

public interface IUser
{
    string Name { get; }
    bool IsNew { get; }
}

public class User : IUser
{
    public string Name { get; private set; }
    public bool IsNew { get; private set; }
}

public class UserService : IUserService
{
    public void ValidateUser(IUser user)
    {
        var repository = RepositoryFactory.GetUserRepository(); // use IoC if needed

        if (user.IsNew && repository.UserExists(user.Name))
            throw new ValidationException("Username already exists");
    }
}

Answer 9

简而言之，您有 4 个选项：

• IsValid 方法：将实体转换为状态（可能无效）并要求它进行自我验证。

• 应用服务中的验证。

• TryExecute 模式。

• Execute / CanExecute 模式。

阅读更多here

Answer 10

创建域服务

或者我可以为 创建和编辑用户。但 有人可以直接编辑用户名 无需调用该服务...

如果您正确设计了实体，这应该不是问题。