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

Question

我是新的广告领域驱动设计，对实体对象有疑问。 对象不应该像下面那样只移动数据。我正在使用 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 等第三方工具创建一个新的通用类来验证实体？领域驱动设计的正确方法是什么？

Answer 1

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

---

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

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

解析器只是一个函数，它消耗结构化程度较低的输入并产生结构化程度更高的输出。 -- 亚历克西斯金

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

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

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

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

---

总而言之，没有人会为“最具 DDD 设计”颁发奖品。 “设计规则”是对模式的一种意见，可以使开发团队的生活更轻松。但是，如果这些规则在您的上下文中不起作用，那么您不应该使用它们。