用户和密码重置 - 不同的聚合？

Question

DDD中的基本内容。

以下是许多基于用户的系统的基本案例。有一个User对象/实体。用户可以创建密码重置（或电子邮件验证），这将触发发送的电子邮件，然后在正确的用户操作后，密码数据将被重置（或者在验证时将验证用户电子邮件）。

在决定用户聚合是否包含密码重置和验证时应该考虑什么，或者那些应该是不同的聚合？

通常，在不考虑聚合时，我正在创建用户，重置，验证的不同集合（io noSQL db）。

不是我正在构建基于EventSourcing的系统，并且考虑如何根据聚合进行设计更好。

我认为这种情况应该是许多项目的典型案例，我将非常感谢有经验的人提供的任何意见。

Answer 1

这些用例受DDD影响，事件来源有点无关紧要。是否创建新的聚合类型取决于不变量和一致性要求（强与最终一致性）。

在这个密码重置的特定用例中，问题是您是否允许被阻止的用户请求重置密码。如果有另一个聚合对此负责，即UserPassword，那么由于两种聚合类型之间的最终一致性，被阻止的用户可能会请求密码重置，这是小的可能性。您可以说它没关系（它对业务没有任何负面影响），因为即使用户请求密码重置，他也无法再进行身份验证，因为用户被阻止了。所以它在很大程度上取决于域名。

一般情况下，您应该支持较小的聚合但不会破坏不变量。你可以阅读Vaughn Vernon关于设计Aggregates的this文章。

  

不是我正在构建基于EventSourcing的系统，并且考虑如何根据聚合进行设计更好。

你应该使用整个DDD方法，而不仅仅是聚合战术模式，还有战略模式，如有界上下文和上下文映射。