DDD：聚合根或实体密钥设计，密钥UUID或唯一编号是否应由系统生成？

Question

在我的业务逻辑中，用户可以通过他/她的手机号码来识别。第三方验证系统确保客户的电话号码真实存在，并在将用户记录插入表格之前检查唯一性。在我看来，PhoneNumber已经是唯一的，所以Id是不必要的。

这是我当前的用户课程PhoneNumber当前是User类中的值对象。

    public class User : AggregateRoot<Guid>
    {
        public Guid Id {get; private set;}
        public PhoneNumber PhoneNumber { get; private set; }
        public Birthday Birthday { get; private set; }
        public Gender Gender { get; private set; }
        public Name Name { get; private set; }
    }

我想改变如下。

public class User : AggregateRoot<string>
{
   public string PhoneNumber { get; private set; }
   public Birthday Birthday { get; private set; }
   public Gender Gender { get; private set; }
   public Name Name { get; private set; }
}

如果在聚合根或实体中使用非UUID Id，是否存在任何缺陷？

Answer 1

不，您可以使用手动生成的ID。如果您正在使用实体框架，并且不想将PhoneNumber name更改为Id，则需要使用[Key]属性，否则实体将无效，因为实体框架将无法识别主键。

Answer 2

PhoneNumber已经是唯一的，所以Id是不必要的。

电话号码分配改变；因此，您需要仔细考虑这对您的设计的影响（您的结论可能是“在这种情况下，我们将对数据进行手动更正”）。

在大多数情况下，关于“自然关键点”和“代理关键点”的争论仍然存在。

如果在聚合根或实体中使用非UUID Id，是否存在任何缺陷？

UUID不是必需的；你可以在正确的条件下使用整数。

一个有用的特性是，系统中的所有对象都具有相同的大小键；您的“标识符”逻辑是通用的，您可以报告有关标识符的信息，而无需提前知道标识的是什么。使用UUID可以实现这一点。

UUID的另一个有趣特性是，我们有从数据计算UUID的标准方法（请参阅“命名UUID”）；因此，您可能会获取一些业务数据——比如电话号码——生成相应的UUID，然后将其用作标识符（这会为您提供所有内容的相同性——UUID——但不会解决“如果电话号码发生变化怎么办？”问题）。

Answer 3

PhoneNumber已经是唯一的，所以Id是不必要的。

除了独特性之外，还有另一个非常重要的考虑因素：电话号码是PII。如果你的软件可能在美国、欧盟，甚至可能是世界上大多数国家使用，你就不能用它作为一个标识符，因为遵守隐私条例是非常困难的。例如，您不能记录它（这将使故障排除变得不可能），并且您需要能够在用户请求删除其数据的任何时候删除它，这在您需要保持数据库中的数据完整性时可能非常棘手（大多数情况下，您可以删除PII，而不删除数据库中的实际记录，但如果您的PK是PII，则会出现问题）。