DDD中从持久化存储读取时，如何处理带时间验证的值对象？

针对你遇到的「从数据库读取值对象时因已过有效期触发验证失败」的问题，以下是几种务实且符合领域驱动设计（DDD）原则的方案：

方案1：区分「新建实例」与「重建已有实例」的构造逻辑 #

核心思路是保留业务场景下的验证规则，同时为ORM提供专门的无验证实例重建入口，且限制该入口的调用范围，避免业务代码误用。

代码实现： #

public DateTime Value { get; }

// 公共构造函数：仅用于业务场景创建新的StartDate，强制验证
public StartDate(DateTime value)
{
    Validate(value);
    Value = value.ToUniversalTime(); // 统一转UTC，避免时区偏差
}

// 私有构造函数：仅用于ORM重建实例，跳过验证
private StartDate(DateTime value, bool skipValidation)
{
    Value = value.ToUniversalTime();
}

// 内部工厂方法：仅供基础设施层（ORM所在项目）调用
internal static StartDate CreateWithoutValidation(DateTime value)
{
    return new StartDate(value, skipValidation: true);
}

// 提取验证逻辑，便于维护
private void Validate(DateTime value)
{
    if (value.ToUniversalTime() < DateTime.UtcNow)
        throw new StartDateCannotBePast(value);
}

额外配置： #

在领域层项目的AssemblyInfo.cs中添加如下配置，允许基础设施层调用内部方法：

[assembly: InternalsVisibleTo("YourInfrastructureProjectName")]

这样业务代码必须通过公共构造函数创建StartDate（强制验证），而EF Core的类型转换可以安全调用CreateWithoutValidation，不会破坏领域规则的封装性。

方案2：调整验证规则的职责边界 #

思考验证规则的本质：你的业务规则大概率是「创建新计划时，StartDate不能为过去时间」，而非「StartDate这个值永远不能是过去时间」（毕竟数据会随时间自然过期）。

此时应将业务规则从值对象的构造函数中剥离，转移到创建实体的领域服务或命令处理程序中，值对象仅负责保证自身数据的完整性（如避免无效的DateTime值）。

代码实现： #

值对象（仅保证数据完整性）：

public DateTime Value { get; }

public StartDate(DateTime value)
{
    if (value == DateTime.MinValue)
        throw new InvalidStartDateException("StartDate不能为默认最小值");
    Value = value.ToUniversalTime();
}

领域服务（负责业务规则验证）：

public class ScheduleItemService
{
    public ScheduleItem CreateScheduleItem(StartDate startDate, /* 其他参数 */)
    {
        // 仅在创建新实体时验证规则
        if (startDate.Value < DateTime.UtcNow)
            throw new StartDateCannotBePast(startDate.Value);
        
        return new ScheduleItem(startDate, /* 其他参数 */);
    }
}

这种方案更符合DDD的职责划分：值对象负责维护自身数据的有效性，业务规则由领域服务或实体行为来保障。从数据库读取实例时，值对象的构造不会触发任何业务规则验证，自然不会报错。

方案对比 #

• 若你的业务规则确实要求「StartDate在任何场景下都不能为过去」（这种情况极少），选择方案1，既能满足ORM需求，又能严格限制无验证入口的调用范围。
• 若规则仅针对「新建实体」，选择方案2，更贴合DDD的设计理念，避免值对象承担超出自身职责的业务规则。

内容的提问来源于stack exchange，提问作者Anon2391