DDD只读存储库返回“值对象”

最后,我觉得我的存储库正在返回有价值的对象。

这对于只读用例完全有意义。

埃里克·埃文斯第一次描述 domain-driven-design ,他一直在从事一项设计,其中“聚合”接口用于读写。因此,您将有一个单一的存储库,它将为应用程序提供根实体。

然而,几年后,格雷格·杨(GregYoung)发表演讲,提出了一种不同的模式;将读职责和写职责分为两个对象。对于处理写操作的用例,实体仍然有意义。

但对于读取,您并没有试图更改标识到状态的映射。因此,您可以通过简单地返回当前状态的副本来支持该用例,即 价值 .

因此,您将拥有一个支持写入的存储库,以及一个或多个支持读取的附加存储库。

如今,这种模式被称为命令查询责任分离,或 cqrs .

就实际实现而言,它完全符合您的预期。支持读取用例的存储库接口返回值对象(内部状态不可变的对象)。

在某些情况下,让存储库只返回一个表示是有意义的。例如,如果您的“应用程序”是需要返回JSON文本的web API,那么您可以让存储库直接返回对象的JSON表示,而不是从域模型中获取的“值对象”。

从存储库返回值对象或其他非实体数据并不是一件坏事。例如,当您需要统计所有客户端时,您不应该从repo获取所有客户端实体,repo应该提供返回整数(值对象)的方法。

但在你的情况下,我想你错过了一些领域概念。看起来您将域逻辑移到了DAL中。如果这是真的,请三思。

考虑将逻辑放入业务层。在某个时间点,业务代码应该加载所有数据,进行计算(检查价格),并使用repo存储现成的数据。就像你在BL中执行连接一样。

只是因为你的

用于连接/处理从各种表中提取的数据的函数

在数据库中运行不会自动使其成为存储库。在我看来,它就像一个返回值对象的服务。您的数据库功能本身可以依赖于类似于存储库的其他功能/结构。