在DDD体系结构中确定存储库和聚合大小和责任

Question

具体（我希望）的问题，如果可能的话，我会喜欢具体的答案......关于聚合的DDD架构和存储库责任以及细粒度级别。

假设我有以下（简化）表：

• customer [id，name，groupId，categoryId]
• customerGroup [id，name]
• customerCategory [id，name]

基本功能（仅显示方法的示例用法）

显示客户列表并单击以显示一个客户。 编辑客户并从所有组的下拉列表中选择组。对于cateogry也一样。

问题

我应该将客户群组和类别视为单独的聚合：

• CustomerRepository。使用方法GetAllCustomers，GetCustomerById等

• CustomerGroupRepository。使用方法GetAllCustomerGroups，GetOneCustomerGroup

• CustomerCategoryRepository。使用方法GetAllCustomerCategories，GetOneCustomerCategory

或仅一个回购 - CustomerRepository（使用上述所有方法，更明确地命名）。

上面的图层将是一个CustomerService，上面注入了一个/多个repos。

我希望能够对如何考虑有关细粒度存储库的优缺点的聚合和相关数据（类别，组）的大小进行思考。仍然保持简单，专注于以一种好的方式解决问题，而不会过度构建内容。

我试图在SO上找到类似的例子，并且还阅读了vaughn vernon的文章，但并没有例如看到他的产品聚合示例如何处理产品类别。

Answer 1

没有特定的聚合模型可以从这个域派生，因为它主要是分层的。你基本上只是在其他容器内的容器内有哑数据结构。看不到不变量或业务规则，也没有明显的并发访问权限。

如果这个域名全部存在，我就不会使用DDD战术模式来模拟它，它只是CRUD。

随着书名的出现，DDD就是在软件中解决复杂性，而不是在简单问题上不必要地解决问题。

Answer 2

用户可以在没有任何客户的情况下创建类别吗？如果您回答是，那么该类别是根聚合，并且应该有一个自己的存储库。

客户群也一样。如果它们只是一种价值，那么你用它标记客户是一个子聚合（或者更确切地说是一个值对象，与标签比较）。如果您应该能够独立创建组，然后将客户附加到它们，则应将它们定义为根聚合。