3 domain-driven-design repository ddd-repositories repository-pattern cqrs
关于存储库模式的一些事情困扰着我
存储库的实际用途是什么?我将其理解为 Domain.Model 的一部分,它提供了在聚合上执行命令的方法,仅此而已。
现在,如果您使用提供 CUD 方法的通用基础存储库,您可能会说您的域不是通用的,因此存储库不是通用的,我同意,但只是从一个角度来看,发出的是查询,而不是命令。
我认为通用存储库至少在 DDD 与 CQRS 混合的背景下消除了对 Domain.Repositories 的需求(我知道我可能听起来有争议,这也正是我的看法)。但是,如果您将命令与查询分开,那么您将拥有仅包含 CUD 操作的 WriteRepositories。因此到处都有很多重复的东西。
想象一下这个
CustomerRepository : ICustomerRepository
{
void Add(CustomerAggregate agg);
void Update(CustomerAggregate agg);
}
BookRepository : IBookRepository
{
void Add(BookAggregate agg);
}
SubscriptionsRepository : ISubscriptionsRepository
{
void Add(SubscriptionAggregate agg);
void Update(SubscriptionAggregate agg);
void Delete(SubscriptionAggregate agg);
}
Run Code Online (Sandbox Code Playgroud)
……另外 5 个仓库
那么,在使用 Command.Stack + Query.Stack 的 CQRS 模式的 DDD 上下文中,通用存储库是否有意义?如果是这样,它是否消除了对 Domain.Repositories(命令存储库)的需要?
存储库的实际用途是什么?
Evans(蓝皮书)的第 6 章相当详细地介绍了存储库模式。存储库“提供了内存中集合的幻觉......”
存储库减轻了客户端的巨大负担,客户端现在可以与一个简单的、意图揭示的界面进行对话,并了解它在模型方面的需求
它们将应用程序和领域设计与持久性技术、多个数据库策略甚至多个数据源解耦。
它不是域模型的一部分,也不直接支持命令执行。相反,它是一种抽象,它将理解域行为(通过聚合根的 API)的代码与理解如何执行数据查找以及如何在持久表示和内存表示之间进行转换的代码分开。
我将其理解为 Domain.Model 的一部分,它提供了在聚合上执行命令的方法,仅此而已。
并不真地?聚合根是域模型的一部分,知道如何组装它们的工厂也是如此。
但存储库实际上并不是域模型的一部分;而是域模型的一部分。领域模型根本不使用存储库;应用程序层使用它们,基础设施层提供实现。
那么,通用存储库在使用 CQRS 模式的 DDD 上下文中是否有意义
好吧,普及 CQRS 模式的人并不是通用存储库接口的忠实粉丝。