领域驱动设计实现聚合

Question

我已阅读有关聚合的创建和职责的信息，但我对如何正确实施它们感到怀疑。假设我们有 2 个实体的上下文。一个是公司，第二个是用户。业务规则在公司实体中，这意味着这应该成为聚合根。对于公司，我们只能分配 3 个用户，当 Comapny 的状态为“被阻止”时，我们不能分配用户。用户也可以使用电子邮件和密码登录。考虑到这一点，用户实体上的每个操作都应该通过聚合根调用，用户不应该有自己的存储库。当没有公司根用户无法直接登录时，如何对用户进行登录操作？我们不能从聚合中调用 User。如何使用提供的电子邮件和密码查找用户？获取所有聚合并迭代其用户效率低下，我认为这不是一个好主意。 谢谢你的帮助。

Answer 1

我认为该用户应该属于另一个 BC（管理身份验证和授权）。在您的公司 BC 中，您必须从认证和授权 BC 中获取用户。您必须将两个 BC 与上下文映射模式集成，其中身份验证和授权 BC 位于上游，而公司 BC 位于下游。

Answer 2

身份验证通常不是域的一部分（在所有用例的 99% 中），只是基础架构的一部分。

因此Users 不应该出现在有界上下文中。在真实的商业世界中，也没有用户，只有 People、Persons、Employees、Managers 或 Contacts 等。

因此，对于日志记录问题，您可以让我们的用户使用用户名 + 密码作为身份验证。这些用户有一个 id（数字、字符串或 guid）。

您的Employee 或Persons 实体/聚合（或您命名它的名称取决于您的域，确切的术语取决于公司 - 无处不在的语言）然后只包含属于该人的数据（但不是识别相关信息）。

然后，您可以将员工连接到用户（通过将员工 ID 设置为用于登录的用户的 ID、额外字段或通过 1:1 或 1:n 查找表）。

通过这种方式，您可以轻松删除用户（登录名）而不删除 Employee 实体，因为在现实世界的场景中，您不能轻易删除业务数据（即想象删除用户会删除每张发票上的收件人或CRM 数据，没有人会知道这个人过去曾在那里工作过）。