如何确定聚合根 - 领域驱动设计

Question

我有一个聚合：用户。
我将如何确定它的聚合根？

因为我有：

   +User(folder)
     - User(Abstract Class)
     * Administrator(Concrete inherits from User)
     * Manager(Concrete inherits from User)
     * Maintenance(Concrete inherits from User)

我还必须为每个用户类（管理员、经理、维护）创建一个存储库吗？ 还是只创建一个使用抽象类（用户）的存储库？

Answer 1

您的问题有两个相关的部分： 首先，我认为您对聚合和聚合根的概念并不准确。因此，重要的是在继续之前让它们正确。

当你有继承关系时，这不是一个聚合问题。聚合适用于组合。原因如下：

让我们举个例子。你有一个抽象类用户，然后你有这些用户的专业化：管理员、经理、维护。现在，这四个不是聚合-聚合-根关系。但是，它们都是聚合根。或者换句话说，每个都是聚合根。

从用户开始，假设这是聚合的聚合根。现在，因为管理员是用户，您可以用管理员替换用户，它成为根。其他专业也一样。

关键是要了解管理员、经理、维护是同一聚合中用户的替换。它们不是用户的对象值。

您问题的第二部分是关于实施的。是为每个子类型实现单独的存储库类还是为所有子类型实现一个单独的存储库类。这个问题的答案取决于您的应用程序的详细信息、您使用的工具类型等。没有硬性规定可以选择两种方式中的哪一种。例如，如果您的子类型只有几个属性不同，最好将它们全部放在单个表和单个存储库中，否则有单独的存储库。例如，Hibernate 框架允许两种方式中的任何一种，由开发人员/设计人员选择。

但是，同样，关键是要考虑这个问题，将其视为继承（它是）而不是聚合/聚合根问题。

Answer 2

首先，如果用户是实体，则取决于您的域。例如，在视频租赁商店中，用户是一个实体，可能是聚合根的良好候选者。但是，如果您要设计一个系统来进行招聘。那么也许用户只是为了登录系统。所有用户都可以做任何事情，并且都具有相同的角色 - 招聘人员。那么也许用户更像是一个基础设施，用户可能只能由一个用户ID代表......在候选人中的某个地方。这完全取决于用户和上下文。

关于继承和存储库：继承是一个很重要的介绍。它可能会导致问题，但也可以降低复杂性。这取决于您是否有许多可以放在基类 User 中的共同行为。然后你可以从多态中得到很多，让只有一个 UserService。然后，UserService 可以在需要时使用 AdministratorRepository 或 ManagerRepository。但是检查你是否可以通过组合而不是继承来解决这个问题。它不会产生太多的耦合。当您想使用新的子类进行扩展时，它会增加一点复杂性。