domain-driven-design - 值对象是否应该包含输入参数的技术验证？

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

as DDD practitioner advise, business rule's validations must be implemented inside domain objects (Entities,Value Objects and Domain Services)

是的。

also somewhere I'd read that we should put technical validations (such as check length,correct input formats,correct data type,...) out of domain model and somewhere like application layer to keep domain object clear.

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

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

所以在你的例子中，借记卡验证逻辑看起来是在正确的地方。

警告 - 您的模型会随着时间的推移而发展；当模型更改时，您仍然需要能够读取模型的早期版本写入的数据。添加将当前数据视为无效的验证规则可能会变得困惑 - 因此您要确保验证规则具有商业动机。您是否通过确保借记卡号码具有有效的校验和来节省资金/削减成本？

(例如:假设客户提交了一个带有无效卡号的采购订单。企业是想拒绝该订单，还是接受该订单但推迟到提供有效的付款方式后才采取行动？如果是后一种选择，您想确保您的验证逻辑不会妨碍接受订单)。