Вроде базовая вещь в DDD.
Вот базовый случай для многих пользовательских систем. Есть объект / сущность "Пользователь". Пользователь может выполнить сброс пароля (или подтверждение по электронной почте), при котором будет отправлено электронное письмо, а затем после правильных действий пользователя данные пароля будут сброшены (или электронная почта пользователя будет проверена в случае проверки).
Что следует учитывать при принятии решения о том, будет ли совокупность пользователей включать сброс паролей и проверки или это должны быть разные агрегаты?
Обычно, когда я не думал об агрегатах, я создавал различные сопоставления (io noSQL db) пользователей, сбросов, проверок.
Не я строю систему на основе EventSourcing и думаю, как лучше спроектировать с точки зрения агрегатов.
Я думаю, что такой случай должен быть довольно типичным для многих проектов, я буду признателен за любой вклад опытных людей.





Эти варианты использования подпадают под действие DDD, источник событий вроде здесь не имеет значения. Создавать ли новый тип агрегата или нет, зависит от инвариантов и требований согласованности (строгая согласованность или согласованность в конечном итоге).
В этом конкретном случае использования сброса пароля вопрос заключается в том, разрешаете ли вы заблокированному пользователю запрашивать сброс пароля или нет. Если за это отвечает другой агрегат, то есть UserPassword, то существует вероятность небольшой, что заблокированный пользователь может запросить сброс пароля из-за возможной согласованности между двумя типами агрегатов. Вы могли бы сказать, что это не имеет значения (это не оказывает никакого негативного влияния на бизнес), потому что даже если пользователь запрашивает сброс пароля, он больше не может аутентифицироваться, потому что пользователь заблокирован. Так что это сильно зависит от домена.
В общем, вам следует отдавать предпочтение более мелким агрегатам, но без нарушения инвариантов. Вы можете прочитать эссе Вона Вернона это о разработке агрегатов.
Not I'm building EventSourcing based system, and thinking how it is better to design in terms of aggregates.
Вы должны использовать весь подход DDD, а не только тактический шаблон Aggregate, но также и стратегические шаблоны, такие как ограниченные контексты и контекстные карты.
Спасибо, я очень ценю ваш вклад