值对象是否包含输入参数的技术验证？

Question

正如DDD从业者所建议的那样,业务规则的验证必须在域对象(实体,值对象和域服务)中实现,并且在我读过的某个地方也遵循他们自己的上下文,我们应该进行技术验证(例如检查长度,正确的输入格式,正确的数据类型,...)域模型和应用层之类的地方,以保持域对象清晰.

现在 我的问题是:

如果我们有信用卡号的价值对象等,我们是否应该从我们的价值对象中保留技术验证？换句话说,当我们处理价值对象时,"自我验证"一词不涉及技术验证？

如果不正确的借记卡号码甚至电子邮件地址都有可能破坏业务规则,那么呢？

为了更加清晰,请注意这个代表借记卡号码的价值对象:

    public class DebitCardNumber : ValueObject
{
    public string Number { get;private set; }

    public CreditCardNumber(string number)
    {
        Validation(number);

        this.Number = number;
    }

    private void Validation(string number)
    {
        if (String.IsNullOrWhiteSpace(number))
        {
            throw new CardNumberCanNotBeEmptyException();
        }

        if (number.Length != 16)
        {
            throw new CardNumberLengthMustBeSixteenDigitException();
        }

        int sum = 0;
        for (int i = 1; i <= 16; i++)
        {
            if (!char.IsDigit(number[i - 1]))
            {
                throw new ValueContainsSomeNonDigitCharacterException();
            }

            int m = (i % 2 == 0 ? 1 : 2);
            int a = (int.Parse(number[i - 1].ToString()) * m);

            while (a > 9)
            {
                a -= 9;
            }

            sum += a;
        }

        if ((sum % 10) > 0)
        {
            throw new ValueIsNotCorrectAsACardNumberException() 
                { Message = "Perhaps some digits has been entered in wrong order or they are incorrect." };

        }
    }
}

根据这段代码,有一种验证方法可以执行算法,以找出卡号的格式是否正确？你觉得这种验证是正确的吗？

Answer 1

正如DDD从业者所建议的那样,业务规则的验证必须在域对象(实体,值对象和域服务)中实现

是.

我还读过某个地方,我们应该从域模型和应用层之类的地方放置技术验证(例如检查长度,正确的输入格式,正确的数据类型......),以保持域对象清晰.

这里有点困惑; 重点是实体不应该担心一堆输入验证,这不是他们的工作(职责分离).因此,我们不是将原始数据(字符串,基元)传递给模型中的实体,而是首先使用基元构造实体将识别的值类型,然后将这些实体传递给.

可以使用基元来创建格式良好的值类型的规则在值类型本身(构造函数)或为此目的提供的专用工厂中正确实现.应用程序组件有责任在将该值传递给模型之前,从它收到的消息/ DTO中创建值类型.

因此,在您的示例中,DebitCard验证逻辑看起来就像它在正确的位置.

谨慎 - 你的模型随着时间的推移而发展; 当模型发生变化时,您仍然需要能够读取模型早期版本所写的数据.添加将当前数据视为无效的验证规则可能会变得混乱 - 因此您需要确保验证规则具有业务动机.您是通过确保借记卡号码具有有效的校验和来节省资金/削减成本吗？

(例如:假设客户提交了一张带有无效卡号的采购订单.企业是否要拒绝该订单,或接受该订单,但推迟采取行动直至提供有效的付款方式？如果是后者选择,则希望确保您的验证逻辑不会妨碍接受订单).