实体类中的域实体验证是正确的方法吗？答案

【问题标题】：Is Domain entity validation in entity class a proper way?实体类中的域实体验证是正确的方法吗？
【发布时间】：2022-08-13 23:08:34
【问题描述】：

我是新的广告领域驱动设计，对实体对象有疑问。对象不应仅移动如下数据。我正在使用 c# 编程语言。

public class Job 
{
    public Guid Id { get; set; }
    public string Title { get; set; }
    public DateTime StartDate { get; set; }
    public DateTime EndDate { get; set; }
}

它应该有一些逻辑，例如：

public class Job 
{
    public Guid Id { get; set; }
    public string Title { get; set; }
    public DateTime StartDate { get; set; }
    public DateTime EndDate { get; set; }
    
    public bool IsActive() { .... }
    
    public bool IsAppliable() { .... }
    
}

但是我在哪里可以验证数据属性验证？它在这样的实体类中吗？（也许使用 getter setter 属性进行验证，而不是使用 Validate() 方法）

public class Job 
{
    public Guid Id { get; set; }
    public string Title { get; set; }
    public DateTime StartDate { get; set; }
    public DateTime EndDate { get; set; }
    
    public bool IsActive() { .... }
    
    public bool IsAppliable() { .... }
    
    public List<string> Validate(){
        List<string> validationErrors = new List<string> ();
        
        if(Title.Length < 3)
            validationErrors.Add(\"Title should be minimum 3 characters\")
        
        if(Title.Length > 300)
            validationErrors.Add(\"Title should be max 300 characters\")
        
        ....
    }
    
}

还是应该使用 FluentValidation 等 3rd 方工具创建一个新的通用类来验证实体？哪个是领域驱动设计的正确方法？

请参阅Validation and DDD 验证和 DDD 可能是一个棘手的组合。如何以不会导致领域知识泄露的方式进行验证？

标签： c# validation domain-driven-design entity

【解决方案1】：

TL;DR：如果您关心的是校对数据输入，那么域模型不是该逻辑的理想场所。

孤立的数据验证通常属于实体之外的某个地方（动机：职责分离）。

如果我们有一些像字符串这样的通用数据结构，并且我们想确保字符串也满足一堆额外的约束，那么通常我们用来实现这一点的工具是parser。

解析器只是一个消耗较少结构化输入并产生更多结构化输出的函数。 --Alexis King

解析通常不是域实体问题；我通常希望在表示层附近的某个地方看到它。例如，如果我们试图验证来自 Web 表单的信息，解析通常会发生在控制器附近。

一个常见的设计选择是使用一种类型来表示值的解析形式——在验证通用数据结构满足我们的约束之后，我们将该数据结构包装在一个承诺这些约束的类型（也称为“值对象”）中已经很满意了。域实体代码与类型交互，而不是与底层数据结构交互。

我们也解析更复杂的数据结构——例如，接受 HTTP 请求实体的逻辑，并解决整个问题（实体是 x-www-form-urlencoded 文档吗？它是否满足我们定义的约束对于键？每个值都满足自己的约束吗？）是一个解析器。

域实体的逻辑通常与策略有关，而不是验证。我通常在这里考虑一个状态机隐喻：领域模型定义了如何从一种状态转换到另一种状态；它不负责哪些状态是有效的，而是负责哪些状态是有效的可达.

话虽如此，没有人会颁发“大多数 DDD 设计”的奖品。 “设计规则”是一种关于模式的意见，可以让开发团队的生活更轻松。但是，如果这些规则在您的上下文中不起作用，那么您不应该使用它们。

【讨论】：