在 DDD 领域模型中，业务层和 View 模型是不同的物质。 View 模型代表领域模型的一些部分。
在 ASP MVC DataAnnotations 和 Fluent Validation Library 中通常用作验证机制。
在域模型和 View 模型之间共享验证的最佳实践是什么？
我不喜欢为每个属性创建自定义验证属性的变体。
附言我们可以通过在 Controller 方法中从域模型更新 ModelState 来手动在 Controller 中应用验证。但这将是两次验证调用(一次通过 View 模型，一次通过域模型)。可能有一种简单的可能性来关闭 ASP.NET MVC 服务器引擎中的 View 模型验证，同时使用 JS 客户端验证。
最佳答案
虽然有一所学校指出 "A domain entity should always be valid" 。简而言之，实体不应包含验证，而是通过检查自身然后抛出异常来强制执行“特定于域”的要求。有些人可能不同意这一点，但这是另一个话题。
想想这个比喻:如果一个人不吃东西，它就会死。如果 User 实体没有 firstName，则会引发异常。
那么谁应该做验证呢？谁应该正确地知道域需要什么？我的答案是域之前的层，在您的情况下是 Controller 。
如果您担心跨多个 Controller 或跨多个操作方法进行重复验证，那么您应该考虑添加另一个名为 “服务层” 的层
服务层
这个服务层的目的是封装(保护)你的领域模型。您可能认为这是您的 Controller ，但实际上他们有不同的职责。对于小项目，服务层和 Controller 可以合二为一。
服务层 + 验证
在验证上下文中，服务层应充当“路障”以保护您的域免于进入无效状态。这是您进行“特定领域”验证的地方。
服务层执行单一职责原则，而不是多个 Controller 或多个操作方法与同一实体交互。
服务层还使您能够添加可测试性。
More about service layer
Tutorial about service layer
Sample implementation of the service layer with Unit Testing
如果您担心在服务层和表示层(带有数据注释)中进行验证，请阅读 https://stackoverflow.com/a/8075115/1027250
关于c# - DDD ASP MVC 验证最佳实践，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/20604378/