DDD: Aggregate root or Entity Key design, Should the key UUID or unique number be generated by the system?

Question

In my business logic, A User can be identified by his/her mobile phone number. 3rd party verification system ensures that the customer's phone number exists in real, and the system checks the uniqueness before insert User record into the table. From my opinion, PhoneNumber is already unique, so Id is unnecessary.

Here is my current User class. PhoneNumber currently is a value object in User class.

    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; }
    }

I want to change like below.

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; }
}

Are there any flaws if I use non-UUID Id in an Aggregate root or an Entity?

score 3 · Answer 1 · answered Jul 20 '20 at 19:41

PhoneNumber is already unique, so Id is unnecessary.

There is another very important consideration at play, apart from uniqueness: phone number is PII. You can't use it as an identifier if your software might be used in the US, the EU, and possibly most of the countries in the world because it'll be very difficult to comply with the privacy regulations. For example, you can't log it (which would make troubleshooting issues impossible) and you need to be able to delete it any time the user requests to have her data removed, which could be really tricky when you need to keep data integrity in the DB (most of the time, you can delete the PII without deleting the actual records in the DB, but if your PK is PII you have a problem).

Thank you for sharing the link. It's a moment to think a while how the heuristic key design could be disaster. — Junsuk Park, Jul 21 '20 at 21:49

score 1 · Answer 2 · answered Jul 13 '20 at 09:43

No, you can use manually generated Ids. If you are using Entity Framework and you don't want to change PhoneNumber name to Id you need to use the [Key] attribute, otherwise the Entity will not be valid because Entity Framework will not recognize the primary key.

VoiceOfUnreason · Accepted Answer · 2020-07-14T02:15:03.157

PhoneNumber is already unique, so Id is unnecessary.

Phone number assignments change; so you'll want to think through the implications of that on your design (your conclusion might be "we'll make manual corrections to the data in that case").

For the most part, the arguments about "natural keys" vs "surrogate keys" still hold.

Are there any flaws if I use non-UUID Id in an Aggregate root or an Entity?

UUID are not required; you can use integers under the right conditions.

One property that can be useful is that all of the objects in your system have the same size key; your "identifier" logic is general purpose, you can report things about identifiers without needing to know in advance what kind of thing is being identified. Using UUID gives you that.

Another interesting property of UUID is that we have standard ways of computing UUID from data (see "Named UUID"); so you might take some business data - like a phone number - generate the corresponding UUID, then use that as the identifier (which gives you sameness - UUID for everything - but does not solve the "what if the phone number changes?" question).

DDD: Aggregate root or Entity Key design, Should the key UUID or unique number be generated by the system?

3 Answers3