14

正如 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." };

        }
    }
}

根据此代码，有一种验证方法可以执行算法来确定卡号的格式是否正确？您认为这是进行此类验证的正确位置吗？

4

4 回答 4

15

正如 DDD 从业者建议的那样，业务规则的验证必须在域对象（实体、值对象和域服务）内实现

是的。

我还在某处读到过，我们应该将技术验证（例如检查长度、正确的输入格式、正确的数据类型……）置于域模型之外，并放在应用层之类的地方，以保持域对象清晰。

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

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

因此，在您的示例中，DebitCard 验证逻辑看起来位于正确的位置。

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

（例如：假设客户提交了带有无效卡号的采购订单。企业是要拒绝该订单，还是要接受该订单但推迟执行该订单，直到提供有效的付款方式？如果是后一种选择，您希望确保您的验证逻辑不会妨碍接受订单）。

于 2016-08-30T18:07:32.463 回答
4

如果我们有一个用于信用卡号等的值对象，我们仍然应该将技术验证排除在我们的值对象之外吗？换句话说，当我们处理值对象时，“自我验证”一词不涉及技术验证？

正确的。应该对域（实体、域服务、vos 等）进行建模，以便它们执行业务规则，而不是技术问题。您的域可能需要区分借记卡和信用卡，但我怀疑企业是否关心卡号本身的格式。卡号的格式和正确性对于基础设施目的很重要，因此可以在该层强制执行格式规则。

于 2017-08-22T04:12:51.830 回答
1

在我看来，您的方法在大多数情况下都是正确的。

如果该号码无效，则它不是真正的借记卡号码。

假设您有一个无法验证的借记卡号。要么您将布尔值valid设置为 false，要么您的代码对您撒谎：它不是借记卡号码。

如果您仍想存储数字，可能出于安全或 UX 目的，您应该在不同的对象中执行此操作，可能在 Entered Form 值对象中。

于 2016-08-30T10:08:19.450 回答
1

我不认为您的示例是技术验证规则-我认为这是借记卡的域规则-如果在银行领域中，借记卡号必须遵循某种模式，那么这是域规则这需要强制执行。

所以我认为你的解决方案是正确的。

于 2016-08-30T10:13:44.783 回答