Design patterns DDD只读存储库返回“；“价值对象”；

我正在构建一个小型定价引擎，但为了组织业务逻辑，我尝试遵循DDD概念

我面临着一个有趣的情况。为了简化我的代码，我依靠db函数来连接/处理从各种表中提取的数据。例如，我有一个函数可以计算“中心”的每日日程安排。此函数的输出不是真正的实体（没有真正的id），并且关联的存储库不支持创建/更新/删除功能

类似地，我使用一个函数来计算基本资源定价（列出资源，检查每个时间范围的价格…）

最后，我感觉我的存储库正在返回有价值的对象

据我所知，存储库应该返回聚合，聚合本身包含实体

那么如何返回数据库中计算的“数据”/“值”对象

谢谢你的帮助，

---

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

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

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

最后，我感觉我的存储库正在返回有价值的对象

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

当Eric Evans第一次描述时，他一直在设计一个“聚合”接口用于读写。因此，您将拥有一个存储库，它将为应用程序提供根实体

然而，几年后，格雷格·杨（Greg Young）发表了一次演讲，提出了一种不同的模式；将读-读职责和写职责分离为两个对象。对于处理写操作的用例，实体仍然是有意义的

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

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

如今，这种模式被称为命令查询责任分离（CommandQueryResponsibilitySeparation，简称CommandResponsibility）

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

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

因为您的

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

---

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

当您说“CQRS”时，您的意思是我应该用一个查询+一个直接访问DbContext的处理程序替换我的实际存储库吗？这样，我将有一个服务“提出”一个查询。我会将我的数组作为输出，并继续该过程。查询将位于域项目中，处理程序位于基础结构层。也