关于c＃：在DDD中放置全局规则验证的位置

Where to put global rules validation in DDD

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

所以，我们有实体用户

1
2
3
4
5
6
7
8
9
10
11
12

public class User : IAggregateRoot
{
private string _name;

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

// other data and behavior
}

和用户存储库

1
2
3
4

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

选项包括：

将存储库注入实体

将存储库注入工厂

在域服务上创建操作

???

每个选项更详细：

1.将存储库注入实体

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

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.在域服务上创建操作

我可以创建用于创建和编辑用户的域服务。但有人可以直接编辑用户名而无需调用该服务...

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

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. ???

您在哪里为实体设置全局验证逻辑？

谢谢！

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

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

实体的主要关注点应该是跟踪业务状态 - 这是一种责任，他们不应该关注验证。

例

1
2
3
4
5

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

两个规格：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

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);
}
}

还有一个验证器：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

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));
}

// ...
}

为了完整性，接口：

1
2
3
4
5
6
7
8
9
10

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

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

笔记

我认为Vijay Patel先前的答案是正确的方向，但我觉得它有点偏。他建议用户实体依赖于规范，我相信这应该是另一种方式。这样，您可以让规范依赖于服务，存储库和上下文，而不会让您的实体通过规范依赖性依赖它们。

参考

一个相关的问题，例如一个很好的答案：域驱动设计中的验证。

Eric Evans在第9章第145页中描述了规范模式在验证，选择和对象构建中的使用。

关于.Net中的应用程序的规范模式的这篇文章可能会引起您的兴趣。

相关讨论

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

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

为了防止某人编辑名称而不验证它，请使规范成为编辑名称的必要方面。您可以通过将实体的API更改为以下内容来实现此目的：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
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.
}
}

你的调用代码看起来像这样：

1
2
3
4
var userRepository = IoC.Resolve<IUserRepository>();
var specification = new UniqueUserNameSpecification(userRepository);

user.SetName("John", specification);

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

相关讨论

那么，调用代码应该可以访问存储库吗？因此，调用者应该是域或应用程序服务。那么，如果调用代码只能调用userRepository.IsNameUnique("John")，那么将规范注入用户实体会带来什么好处呢？

@lazyberezovsky：通过使规范成为SetName签名的一部分，调用代码可以立即看到名称必须遵循某个规范。如果依赖于"外部"代码来调用userRepository.IsNameUnique("John")，则无法确保该名称实际上是唯一的，因为外部代码可以轻松省略对存储库的调用。

我真的很喜欢这种方法！这是完全融合的明确足以让消费代码在调用User.SetName时理解对UniqueUserNameSpecification的依赖，模拟规范的能力，以及足以知道实体的"安全"仍在处理用户名验证依赖其他一些代码/层来调用它。例如。依赖于服务层在.Create()方法调用期间调用规范。这样，您的实体将永远不会被允许进入无效状态，这是目标。

还有一个快速的评论。当您创建用户(通过构造函数)时，将无法传入IUserRepository以传递给CreateUser方法。将存储库传递给构造函数中的实体似乎是一件"坏事"，所以从理论上讲，这个实体可能会在无效状态下创建。我唯一能想到的就是允许使用空白名称属性创建User实体，并且在调用User构造函数之后，make使用代码使用SetName方法为User分配名称。

@indiecodemonkey听起来这是一个很好的方法。此外，您可以将所有创建逻辑封装在构建器类中，该类不会暴露"空白"实例，直到它处于完全有效状态。

@Neils van der Rest：基本上，一个简单的工厂？

@indiecodemonkey Factory和Builder模式之间有一些区别，但是，这是一般的想法:)

我不会将Repo注入规范。我会传递你需要的任何数据来满足你的规范。在构造函数中，我会保护我需要验证的数据实际上是通过的，否则我会抛出异常。这样我就不会'间接'将Repo注入域中，这在DDD中是NO NO。

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
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并不重要，因为规则将始终执行。

在这里了解更多

相关讨论

将验证放入setter的缺点是它隐藏了对规范的依赖性。更改属性也应该是轻量级操作，如果规范调用数据库或Web服务则不是这种情况。

皮肤猫的方法有很多种。重点是突出显示规范模式，并显示DDD比服务和存储库更多。我担心在服务或存储库中倾倒太多方法最终会导致较弱的域模型 - 一个更难与域专家通信的域(DDD存在的原因)。

当然，DDD不仅仅是设计模式。但是暴露规范依赖对我来说似乎是件好事，因为它清楚地表明名称不仅仅是任何字符串。你不妨去整个九码并引入一个UserName类。越强越好:)

上面代码的一个问题 - 在更改名称之前调用IsSatisifiedBy(this)。所以，它总是如此。您可以先设置名称。但在这种情况下，您可以将User对象保留为无效状态。

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

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

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

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

相关讨论

(1)我认为性能不取决于我们是从构造函数还是从调用者进行数据库调用 - 无论如何我们都需要进行调用。 (2)我谈到了向工厂注入存储库。使用不可变对象看起来很好。但是如果需要在对象的生命周期中检查全局规则，我们就不能使用工厂了。 (3)域服务是全局逻辑的很好的候选者。但我认为域服务的目的是协调几个对象的交互，所以也许它也是错误的地方？

@lazyberezovsky：(1)我的首选是保持构造函数的简单和副作用，否则使用工厂。当处理100个实体时，并不总是需要执行100个单独的数据库调用，通常在处理大型实体集时优化到更少的数据库往返。通过将所有逻辑放在实体中，您将剥夺自己处理与单个实体不同的大型实体集的可能性。 (2)没错，但你可以使用工厂，还有域名服务。

@lazyberezovsky：(3)DDD是关注领域的，我们需要注意使它成为教条，所以我们应该始终考虑实现技术和(性能)要求。 BTW域服务似乎也是所有类型模式的捕获所有短语，可用于实现协调实体操作的解决方案。

在我的CQRS框架中，每个Command Handler类还包含一个ValidateCommand方法，然后该方法调用Domain中的相应业务/验证逻辑(主要实现为Entity方法或Entity静态方法)。

所以调用者会这样做：

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

每个专用的Command Handler都包含包装器逻辑，例如：

1
2
3
4
5
6
7
8
9
10
public ValidationResult ValidateCommand(MakeCustomerGold command)
{
var result = new ValidationResult();
if (Customer.CanMakeGold(command.CustomerId))
{
//"OK" logic here
} else {
//"Not OK" logic here
}
}

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

相关讨论

有趣的一点。我认为这是选项的变化(3)

我喜欢选项3.最简单的实现看起来如此：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
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");
}
}

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

相关讨论

那么，你建议使用选项(3)，但使用单独的验证方法？

是的，只需从create user方法内部调用验证方法即可。如果返回false，则抛出异常。

Create domain service

Or I can create domain service for
creating and editing users. But
someone can directly edit name of user
without calling that service...

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

相关讨论

设计很简单 - 只是属性名称。

这就是我所说的，但也许不是......"明白"：D

-1我不认为这是一个有用的答案。我不明白为什么它被投票，