DDD - Моделирующий пользователь с контактной информацией, которая должна быть уникальной для всей системы

Question

Мне нужны некоторые пояснения по моделированию пользователя для идентификации и доступа к домену. Модель пользовательского домена имеет объект контактной информации (объект, поскольку он является изменяемым), клиент может зарегистрироваться по номеру телефона, но может изменить его при необходимости.

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

Если создание службы домена в порядке, то каким должен быть репозиторий, так как агрегат не идентифицирован. В этих случаях у меня есть совокупность клиентов (пользователей), но чтобы разрешить всем пользователям запрашивать, используется ли уже предоставленный клиентом номер телефона кем-то еще, каким должен быть агрегат, или я могу написать DomainService, который просто можно запросить базу данных непосредственно к таблице номеров телефонов, чтобы проверить уникальность, нарушаю ли я какой-либо принцип DDD, каковы более чистые альтернативы.

Answer 1

Альтернативой может быть создание Aggregate, в котором будет четко указано, в какой области вы хотите сохранить уникальное ограничение.

В качестве (надуманного) примера, телефонный номер может быть уникальным в разных странах, но не на международном уровне. Таким образом:

// An Aggregate Root
public class Country {

  // Store a lookup structure (userId, phoneNumber) here

  public void addUser(userId, phoneNumber) {
    // check phone uniqueness here
  }

  public void changeUserPhone(userId, phoneNumber) {
    // check phone uniqueness here
  }
}

Поскольку вы используете CQRS, телефонные номера, находящиеся в отдельном Агрегате, не имеют значения, потому что на стороне запроса модели чтения будут повторно собирать пользователя и его phoneNumber вместе.

Это также хорошо согласуется с подходом "не создавать совокупные корни", поскольку у вас есть отправная точка для создания своего пользователя (пользователь, вероятно, AR), а не просто для его создания из воздуха.

Answer 2

Вы можете проверить в своем хранилище, существует ли номер телефона, если он существует, тогда выведите исключение из правила, иначе сохраните изменение. Ключевым моментом здесь является внедрение экземпляра хранилища через уровень приложения и запуск правила внутри уровня домена.