好吧，即使您通过声明一个IUserValidator接口将您的域与框架隔离开，我也看到了您的设计中的一些问题。
最初，这是否会导致与存储库和其他基础架构问题相同的抽象策略，但是我认为这有很大的不同。
使用时repository.save(...)，实际上从域的角度来讲您根本不在乎所有实现，因为如何持久化事物并不是域关注的问题。
但是，不变的执法是一个领域关注的问题，您不必深入研究基础架构的详细信息（UserValidtor现在可以这样看）以了解其组成，而从根本上讲，这就是您要做的最终事情，因为规则将以框架术语表达，并且将在领域之外。
为什么要住在外面？
domain -> IUserRepository
infrastructure -> HibernateUserRepository
domain -> IUserValidator
infrastructure -> FluentUserValidator
也许您的设计存在一个更根本的问题，如果您遵守以下规则，则您甚至都不会问这个问题：始终有效的实体。
从这个角度来看，不变的执行是域实体本身的责任，因此，即使没有有效的执行，它也不应该存在。因此，不变规则可以简单地表示为合同，而违反则抛出异常。
其背后的原因是，许多错误是由于对象处于它们本不应该处于的状态这一事实而来的。揭露我从格雷格·杨读来的一个例子：
我们的提议，我们现在有一个SendUserCreationEmailService，需要一个UserProfile......我们怎么能在服务，合理化Name是不是null？我们会再次检查吗？或更可能的是……您只是不想打扰并“希望最好”，您希望有人在将其发送给您之前先进行验证。当然，使用TDD时，我们应该编写的第一个测试之一是，如果我给客户发送了一个null名称，它将引发错误。但是，一旦我们开始一遍又一遍，我们知道写这些类型的测试......“等，如果我们决不允许名称成为空，我们不会有所有这些测试” - Greg Young的评论上http://jeffreypalermo.com / blog /始终有效实体的谬误/
现在不要误会我，显然您不能以这种方式执行所有验证规则，因为某些规则特定于某些禁止这种方法的业务操作（例如，保存实体的草稿副本），但是这些规则将不被查看与不变执法相同的方式，不变规则是适用于每种情况的规则（例如，客户必须具有名称）。
如果现在查看您的代码并尝试应用始终有效的方法，则可以清楚地看到该UserValidator对象没有放置它的位置。
UserService : IUserService
{
public void Add(User user)
{
//We Couldn't even make it that far with an invalid User
new UserValidator().ValidateAndThrow(user);
userRepository.Save(user);
}
}
因此，目前在域中没有FluentValidation的位置。如果您仍然不确定，请问自己如何整合价值对象？每次实例化值对象时，您是否都会有一个UsernameValidator验证Username对象？显然，这没有任何意义，使用价值对象很难与非总是有效的方法集成。
这实际上是我一直在努力的事情，而且我已经问了自己一段时间了（而且我仍然不完全相信我会说的话）。
基本上，我已经了解到，收集和返回错误不是域的工作，而是UI的问题。如果无效的数据使它到达了域，它只会抛出您的信息。
因此，像FluentValidation这样的框架将在UI中找到其自然的家，并将验证视图模型而不是域实体。
我知道，似乎很难接受会有一定程度的重复，但这主要是因为您可能是像我这样的全栈开发人员，负责处理UI和域，而实际上可以并且应该查看它们作为完全不同的项目。同样，就像视图模型和域模型一样，视图模型验证和域验证可能相似，但用途不同。
另外，如果您仍然担心DRY，那么有人曾经告诉我代码重用也是“耦合”的，我认为这一点在这里特别重要。
在这里，我将不再赘述，但是有多种方法可以处理该域中的延迟验证，例如Ward Cunningham用Checks模式语言描述的“规范”模式和“延迟验证”方法。如果您拥有Vaughn Vernon的《实施领域驱动的设计》一书，则也可以阅读第208-215页。
验证是一个非常困难的主题，并且证明到今天为止，人们仍然对如何完成验证尚无共识。有很多因素，但是最后您想要的是一个实用，可维护且富有表现力的解决方案。您不能始终是一个纯粹主义者，必须接受某些规则将被破坏的事实（例如，为了使用您选择的ORM，您可能必须泄漏实体中的一些不引人注意的持久性细节）。
因此，如果您认为可以接受某些FluentValidation详细信息进入您的域并且这样更实用的事实，那么我就无法确定从长远来看它是否弊大于利，但是我不会。
602392714
清零编程群