DDD模型中，已知数值非负时哪种设计方案更优？

问题场景：当领域模型里的某个数值（比如这里的Quantity）明确不可能为负数时，下面两种C# record的设计方案，哪种更适合DDD的思路？

方案一：用uint类型约束 #

public record Quantity(uint Number);

方案二：用int加构造函数校验 #

public record Quantity()
{
    public int number { get; init; }
    public Quantity(int number)
    {
        if (number < 0) throw new ArgumentOutOfRangeException("Quantity must be positive");
    }
}

两种方案的优劣对比 #

方案一的好与坏 #

• 优点：
  • 直接利用C#的类型系统做约束，编译阶段就能挡住负数输入，根本到不了运行时抛异常那一步，性能更优，代码也更简洁。
  • 类型本身就带着“非负”的领域语义，其他开发者一看uint就懂这个值不能是负的，不用额外看注释或构造函数，可读性拉满。
• 缺点：
  • uint在.NET里不如int常用，要是和一些只接受int的API交互，就得手动做类型转换，多了点麻烦。
  • 万一以后领域规则调整（虽然题目说已知不可能为负，但做长远考量的话），或者需要和大量int类型的领域对象协作，转换成本会更高。

方案二的好与坏 #

• 优点：
  • 用的是最通用的int类型，和现有大部分.NET代码、第三方API交互都不用额外处理，兼容性更好。
  • 构造函数的校验逻辑灵活，要是以后领域规则改了（比如要求数值必须大于0而不是≥0），直接改校验条件就行，不用动类型定义。
• 缺点：
  • 校验是在运行时才触发的，编译阶段发现不了负数输入，只有实例化对象的时候才会报错，可能要等到代码跑起来才知道出问题。
  • int类型本身没带“非负”的语义，别人用这个类的时候，得特意看构造函数或者注释才知道有不能为负的约束，容易踩坑。

该怎么选？ #

如果你的领域规则确定长期不会改（就是不能为负），而且和其他系统交互时uint的转换成本可以接受，那果断选方案一——它把领域规则直接固化在类型里，完美贴合DDD“用代码表达领域语义”的核心思路，从根源上避免了非法值。

要是领域规则可能有调整空间，或者项目里全是int类型，不想因为uint搞一堆转换，那方案二更合适——灵活性拉满，同时靠运行时校验守住了领域规则的底线。

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