代码之家 › 专栏 › 技术社区 › Joseph Ferris

DDD存储库了解其他存储库

ddd-repositories domain-driven-design architecture language-agnostic

7

Joseph Ferris · 技术社区 · 15 年前

一个存储库可以访问另一个存储库,这通常是可以接受的吗?特别是在本例中,我有一个聚合根,它使用另一个聚合根来确定要添加哪些实体。它属于物料/物料类型关系的行。项目类型是聚合根的原因是它们可以在任何单个项目范围之外的管理工具中单独维护。

如果这真的很重要,那么我只是通过一个知识库工厂实现来创建我的知识库实例,所以我不是直接用具体的类名来创建它。对存储库的聚合在任何时候都不知道。

编辑-更多信息:

具体的实现是我们可以将图像附加到文档中。我们不仅可以管理文档中的图像,还可以管理不同类型的图像(例如,类型定义为如何实现,而不是扩展)。文档聚合是系统中使用这些图像的其他几种类型的对象之一,它们不都使用相同的类型。虽然我们在域服务中附加了规则,但这更专门用于构建文档聚合。在构建聚合时,我们有五个特定类型的图像,以及两个其他类型中的一个。我们单独拉这些,因为它们存储在聚合的单独列表中。验证不是问题,而是限制组装文档时要评估的图像类型。

1 回复 | 直到 14 年前

1

6

John Foster 14 年前

我想归根结底就是你想做什么。如果这是一种验证步骤(例如,删除所有项目类型已过期的项目),您可能会认为它属于服务层或规范。从您使用的语言(即“确定要添加的实体”)来看,它似乎建议使用后者,但如果没有更多的细节,就很难说了。

我想从某种角度来看,你不能这样做没有真正的原因(我绝对不是超级DDD最纯粹的),特别是因为一个项目和它的类型可以被视为一个聚合根,并且它只是你需要提供一个管理控制台来防止的实现细节。

从另一个角度来看,它确实表明你的聚合根之间存在模糊,这可能表明两个不同的上下文正在工作。例如,有人可能会争辩说,管理工具为您的主应用程序形成了一个单独的有界上下文,因此项目类型是聚合根的情况并不真正适用。例如,管理工具可能只关注项目类型(而不是项目),而主应用程序可能将项目类型视为比实体更重要的值对象。

更新

正如您提到的组装文档一样,这似乎是一个工厂类的责任,它可以正确地组装一个有效的实体(工厂可以使用图像类型存储库)。存储库(在我看来)应该公开查询和添加操作,而不是配置实体的逻辑(可能是由于持久性而重新水化)。