DDD: Совокупный root или дизайн ключа объекта. Должен ли системой создаваться UUID ключа или уникальный номер?

Question

В моем рабочем журнале c, A User можно узнать по номеру его / ее мобильного телефона. Сторонняя система проверки гарантирует, что номер телефона клиента существует на самом деле, а система проверяет уникальность перед тем, как вставить User запись в таблицу. На мой взгляд, PhoneNumber уже уникален, поэтому Id не нужен.

Вот мой текущий класс User. 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; }
}

Есть ли какие-нибудь fl aws, если я использую не -UUID в агрегате root или в объекте?

Answer 1

PhoneNumber уже уникален, поэтому идентификатор не нужен.

Назначение номеров телефонов изменить ; поэтому вы захотите продумать, как это повлияет на ваш дизайн (ваш вывод может быть таким: «в этом случае мы внесем исправления в данные вручную»).

По большей части, аргументы о «естественные ключи» и «суррогатные ключи» все еще остаются в силе.

Есть ли какие-нибудь fl aws, если я использую не-UUID Id в агрегированном root или Entity?

UUID не требуются; вы можете использовать целые числа при правильных условиях.

Одно свойство, которое может быть полезно, - это то, что все объекты в вашей системе имеют ключ одинакового размера; ваш «идентификатор» logi c является универсальным, вы можете сообщать об идентификаторах, не зная заранее, что именно идентифицируется. Это дает использование UUID.

Еще одно интересное свойство UUID - это то, что у нас есть стандартные способы вычисления UUID из данных (см. «Именованный UUID»); поэтому вы можете взять некоторые бизнес-данные - например, номер телефона - сгенерировать соответствующий UUID, а затем использовать , что в качестве идентификатора (который дает вам одинаковость - UUID для всего, но не решает вопрос «что, если телефон номер меняется? »вопрос).

Answer 2

PhoneNumber уже уникален, поэтому идентификатор не нужен.

Помимо уникальности, здесь есть еще одно очень важное соображение: номер телефона - это PII . Вы не можете использовать его в качестве идентификатора, если ваше программное обеспечение может использоваться в США, ЕС и, возможно, в большинстве стран мира, потому что будет очень сложно соблюдать правила конфиденциальности. Например, вы не можете зарегистрировать его (что сделало бы невозможным устранение проблем), и вам нужно иметь возможность удалить его в любое время, когда пользователь запрашивает удаление своих данных, что может быть очень сложно, когда вам нужно сохранить целостность данных в БД (в большинстве случаев вы можете удалить PII, не удаляя фактические записи в БД, но если ваш PK является PII, у вас есть проблема).

Answer 3

Нет, вы можете использовать идентификаторы, сгенерированные вручную. Если вы используете Entity Framework и не хотите менять имя PhoneNumber на Id, вам необходимо использовать атрибут [Key], иначе Entity не будет действительным, потому что Entity Framework не распознает первичный ключ.