如何优雅重构多可空ValueObject的空值检查逻辑？

一、先解决转换逻辑的冗余与风险 #

你当前的转换代码存在两个明显问题：一是重复写三元表达式冗余，二是直接取Result.Value会忽略验证失败的情况（若Create返回失败，直接取Value可能抛出异常）。可以通过扩展方法封装通用转换逻辑：

public static class ValueObjectConversionExtensions
{
    public static Result<ValueObject?> CreateValueObjectOrNull(this string? rawValue)
    {
        if (rawValue is null)
        {
            return Result.Success<ValueObject?>(null);
        }

        var createResult = ValueObject.Create(rawValue);
        return createResult.IsSuccess 
            ? Result.Success<ValueObject?>(createResult.Value) 
            : Result.Failure<ValueObject?>(createResult.Error);
    }
}

使用时只需一行代码，同时保留错误处理能力：

var valueObjectResult = request.ValueObject.CreateValueObjectOrNull();
if (!valueObjectResult.IsSuccess)
{
    // 处理验证失败，比如返回错误响应
    return Result.Failure(valueObjectResult.Error);
}
var valueObject = valueObjectResult.Value;

二、从设计层面优化可空ValueObject的场景 #

如果业务中大量存在可空ValueObject，说明当前设计的语义不够清晰，可以从以下两个方向调整：

1. 拆分「可选」与「必填」的ValueObject #

针对可选场景，单独定义支持空值的OptionalValueObject，复用原有验证逻辑，同时明确语义：

public class OptionalValueObject : SimpleValueObject<string?>
{
    private OptionalValueObject(string? value) : base(value) { }

    public static Result<OptionalValueObject> Create(string? rawValue)
    {
        if (rawValue is null || string.IsNullOrWhiteSpace(rawValue.Trim()))
        {
            return Result.Success(new OptionalValueObject(null));
        }

        // 复用原有ValueObject的验证规则
        var validationResult = ValueObject.Create(rawValue);
        if (validationResult.IsFailure)
        {
            return Result.Failure<OptionalValueObject>(validationResult.Error);
        }

        return Result.Success(new OptionalValueObject(validationResult.Value.Value));
    }
}

业务类中直接使用非可空的OptionalValueObject，避免可空类型的滥用：

public class MyClass {
    public OptionalValueObject ValueObject { get; protected set; }
    // 其他属性
}

2. 用Null Object模式替代可空类型 #

如果业务允许ValueObject存在「合法空状态」，可以引入Null Object，让属性始终非可空，语义更统一：

public class ValueObject : SimpleValueObject<string>
{
    // 定义全局空实例
    public static readonly ValueObject Empty = new ValueObject(string.Empty);

    private ValueObject(string value) : base(value) { }

    public static Result<ValueObject> Create(string? value)
    {
        if (value is null || string.IsNullOrWhiteSpace(value))
        {
            return Result.Success(Empty);
        }

        var trimmedValue = value.Trim();
        if (trimmedValue.Length != 12)
        {
            return Result.Failure<ValueObject>("ValueObjectLengthRestriction");
        }

        if (trimmedValue.Any(x => !char.IsDigit(x)))
        {
            return Result.Failure<ValueObject>("ValueObjectDigitRestriction");
        }
        
        return Result.Success(new ValueObject(trimmedValue));
    }
}

业务类属性改为非可空，默认赋值空实例：

public class MyClass {
    public ValueObject ValueObject { get; protected set; } = ValueObject.Empty;
    // 其他属性
}

应用层转换时无需处理null，直接调用ValueObject.Create(request.ValueObject)即可，同时保留完整的验证逻辑。

三、原设计的核心问题总结 #

1. 语义模糊：用可空类型ValueObject?无法明确表达「该属性是可选的，还是必填但暂未赋值」，容易造成业务理解偏差。
2. 错误处理缺失：直接取Create().Value忽略了验证失败的场景，可能引发未捕获的异常。
3. 代码冗余：重复的三元表达式增加了维护成本。

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