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

Question

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

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

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

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

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

题

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

• CustomerRepository.使用方法GetAllCustomers,GetCustomerById等

• CustomerGroupRepository.使用方法GetAllCustomerGroups,GetOneCustomerGroup

• CustomerCategoryRepository.使用方法GetAllCustomerCategories,GetOneCustomerCategory

或者只有一个repo - CustomerRepository(具有上述所有方法,更明确地命名).

上面的层将是一个CustomerService,上面注入了一个/多个repos.

我想对如何考虑聚合和相关数据(类别,组)的大小以及细粒度存储库的优缺点进行思考.仍然保持简单,专注于以一种好的方式解决问题而不过度构建东西.

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

Answer 1

没有特定的聚合模型可以从该域派生,因为它主要是分层的.你基本上只是在其他容器内的容器内有哑数据结构.看不到不变量或业务规则,没有任何部分将在重要的并发访问之下.

如果这就是这个领域的全部内容,我不会费心使用DDD战术模式来模拟它,它只是CRUD.

随着书名的出现,DDD的目的是解决软件的复杂性问题,而不是在简单的问题上不必要地解决问题.