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

时间:2013-06-09 11:27:18

标签: c# oop repository domain-driven-design domain-model

我有一个聚合:用户。
我如何确定其聚合根?

因为我有:

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

我是否还必须为每个用户类(管理员,经理,维护)创建一个存储库? 或者只创建一个使用抽象类(User)的存储库?

2 个答案:

答案 0 :(得分:4)

您的问题有两个,但相关部分: 首先,我认为聚合和聚合根的概念并不准确。因此,在向前迈进之前让它们正确是很重要的。

如果您有继承关系,则这不是聚合问题。 Aggregate适用于组合。原因如下:

让我们举个例子。您有一个抽象类User,然后您具有User:Administrator,Manager,Maintenance的这些特化。现在,这四个不是聚合 - 聚合 - 根关系。但是,它们都是聚集的根源。或者换句话说,每个都是聚合根。

从用户开始,假设这是聚合的聚合根。现在,因为管理员是一个用户,您可以用管理员替换用户,它就成了根用户。其他标准也是如此。

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

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

但是,关键是要考虑这个问题,因为继承(它不是聚合/聚合根问题)。

答案 1 :(得分:1)

首先,如果用户是实体,则取决于您的域名。例如,在视频租赁商店中,用户是一个实体,可能是聚合根的良好候选者。但是,如果你要设计一个系统,让我们说招聘。那么也许用户只是为了登录系统。所有用户都可以做所有事情,并且所有用户都有相同的角色 - 招聘人员。那么也许用户更多的是基础设施,用户可能只能由用户ID代表......在候选人之间。这一切都取决于用户和背景。

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