architecture - 确定 DDD 架构中的存储库和聚合大小以及责任

Question

这是一个具体的(我希望)问题，如果可能的话，我希望得到一个具体的答案......关于聚合和存储库责任以及细粒度级别的 DDD 架构。

假设我有以下(简化的)表格:

• 客户 [id、名称、groupId、categoryId]
• 客户组[id，名称]
• 客户类别 [id、名称]

基本功能(仅用于展示方法的示例用法)

显示客户列表并单击以显示一位客户。编辑客户并从所有组的下拉列表中选择组。类别也是如此。

问题

我是否应该将客户组和类别视为单独的聚合:

• 客户存储库。使用 GetAllCustomers、GetCustomerById 等方法

• CustomerGroupRepository。使用方法 GetAllCustomerGroups、GetOneCustomerGroup

• CustomerCategoryRepository。使用方法 GetAllCustomerCategories、GetOneCustomerCategory

或者只有一个存储库- CustomerRepository(具有上述所有方法，更明确地命名)。

上面的层将是一个客户服务，上面注入(inject)一个/多个存储库。

我希望获得一些关于如何思考聚合和相关数据(类别、组)的大小以及细粒度存储库的优缺点的意见。仍然保持简单并专注于以良好的方式解决问题，而不需要过多的架构。

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

Answer 1

没有从该域派生的特定聚合模型，因为它主要是分层的。基本上，您只是在其他容器内的容器内有愚蠢的数据结构。看不到不变量或业务规则，也没有暗示将受到大量并发访问的部分。

如果这就是这个领域的全部内容，我就不会费心使用 DDD 战术模式对其进行建模，它只是 CRUD。

正如书名所说，DDD 是关于解决软件中的复杂性，而不是在简单的问题上不必要地费力。