7 design-patterns domain-driven-design
我正在构建一个小型定价引擎，但为了组织业务逻辑，我尝试遵循 DDD 概念。
我面临着一个有趣的情况。为了简化我的代码，我依靠 db 函数来连接/处理从各个表中提取的数据。例如，我有一个函数可以计算“中心”的每日时间表。该函数的输出并不是真正的实体（没有真正的 ID），并且关联的存储库不支持创建/更新/删除功能。
同样，我使用一个函数来计算基本资源定价（列出资源，检查每个时间范围的价格...）。
最后，我感觉我的存储库正在返回值对象。
据我所知，存储库应该返回聚合，它们本身包含实体。
那么如何返回数据库中计算的“数据”/值对象呢？
谢谢你的帮助，塞巴斯蒂安
最后，我感觉我的存储库正在返回值对象。
这对于只读用例来说完全有意义。
当 Eric Evans 第一次描述领域驱动设计时，他一直在从事一种设计，其中“”聚合接口用于读取和写入。因此，您将拥有一个存储库，它将为应用程序提供根实体。
然而几年后，格雷格·杨（Greg Young）在一次演讲中提出了一种不同的模式；读取职责和写入职责分为两个对象。对于处理写入的用例，实体仍然有意义。
但对于读取，您并不试图更改身份到状态的映射。因此，您可以通过简单地返回当前状态的副本（即值）来支持该用例。
因此，您将拥有一个支持写入的存储库，以及一个或多个支持读取的附加存储库。
如今，该模式被称为命令查询职责分离，或cqrs。
就实际实施而言，它完全符合您的预期。支持读取用例的存储库接口返回值对象（内部状态不可变的对象）。
在某些情况下，让存储库只返回一个表示是有意义的。例如，如果您的“应用程序”是需要返回 JSON 文本的 Web API，那么您可以让存储库直接返回对象的 json 表示形式，而不是从域模型获取的“值对象”。