User и PasswordReset - разные агрегаты?

Question

Вид базовых вещей в DDD.

Вот базовый случай для многих пользовательских систем.Существует объект / сущность пользователя.Пользователь может создать сброс пароля (или подтверждение по электронной почте), который будет инициировать отправку электронной почты, а затем после правильных действий пользователя будут сброшены данные пароля (или электронная почта пользователя будет проверена в случае проверки).

Что должно бытьучитывается при принятии решения, будет ли агрегат пользователя включать в себя сброс и проверку пароля, или это должны быть разные агрегаты?

Обычно, когда я не думал о агрегатах, я создавал разные коллизии (io noSQL db) пользователей, сбрасывает, Проверки.

Не я строю систему на основе EventSourcing, и думаю, как лучше проектировать с точки зрения агрегатов.

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

Answer 1

Эти сценарии использования зависят от DDD, источник событий вроде здесь не имеет значения.Создавать ли новый тип агрегирования или нет, зависит от инвариантов и требований согласованности (сильная или окончательная согласованность).

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

В общем, вы должны отдавать предпочтение меньшим агрегатам, но без нарушения инвариантов.Вы можете прочитать это эссе Вона Вернона о проектировании Агрегатов.

Не я создаю систему на основе EventSourcing и думаю, как лучше проектировать с точки зрения агрегатов.

Вы должны использовать весь подход DDD, не только совокупный тактический паттерн, но и стратегические паттерны, такие как ограниченный контекст и контекстные карты.