使用一个存储库使用另一个存储库不遵循DDD的原则。如果您需要来自一个聚合根的数据以对另一个聚合根执行某些操作，则可以检索第一个根（在应用程序服务层或可能在域服务中），然后将该数据传递到从属聚合根的公共api中，或者在使用单独工厂的聚合根创建的情况下，将其添加到工厂的公共api中。
一个存储库可以访问另一个存储库通常被接受吗？特别是在这种情况下，我有一个聚合根，该聚合根使用另一个聚合根来确定要添加的实体。它遵循“项目/项目类型”关系的线。项目类型是聚合根的原因是，它们可以在任何单个项目范围之外的管理工具中单独维护。
[如果确实很重要，我只是通过存储库工厂实现来创建我的存储库实例，因此我不会直接通过具体的类名创建它。聚合永远不会知道存储库。
编辑-更多信息：
具体实现是我们可以将图像附加到文档。我们不仅可以管理文档上的图像，而且还可以使用不同类型的图像（例如，类型定义为实现方式，而不是扩展名）。文档聚集是系统中使用这些图像的其他几种对象之一，它们并不都使用相同的类型。尽管我们确实在域服务中附加了规则，但更具体地讲，它适用于构建文档聚合。构建聚合时，我们有五种特定类型的图像，以及两种其他类型的图像。我们将它们分别拉出，因为它们存储在聚合中的单独列表中。验证不是问题，而是在组装文档时限制要评估的图像类型。
我想这归结为您要尝试做的事情。如果这是一种验证步骤（例如，删除所有商品类型已过期的商品），则可以说它属于服务层或规范。从您使用的语言（即“确定要添加的实体”）看来，似乎建议后者，尽管没有更多细节很难说。
我想从某种角度来看，您没有理由不这样做（我绝不是超级DDD最纯洁的人），尤其是因为一个项及其类型可以被视为一个聚合根，而这仅仅是您需要提供一个预防性的管理控制台的实施细节。
从另一个角度看，这似乎表明您的聚合根之间存在模糊，这可能表明存在两种不同的情况。例如，有人可能会说管理工具对您的主应用程序形成了一个单独的有界上下文，因此Item类型为聚合根的情况实际上并不适用。例如管理工具可能只涉及项目类型（而从来没有涉及项目），而您的主应用程序可能将项目类型视为价值对象而不是实体。
更新
正如您提到的那样，组装文档似乎是工厂类的责任，该类可以正确地组装有效的实体（工厂可以使用图像类型存储库）。在我看来，存储库应该公开查询和添加操作，而不是配置实体的逻辑（除了可能从持久性中恢复活力）。
使用一个存储库使用另一个存储库不遵循DDD的原则。如果您需要来自一个聚合根的数据以对另一个聚合根执行某些操作，则可以检索第一个根（在应用程序服务层或可能在域服务中），然后将该数据传递到从属聚合根的公共api中，或者在使用单独工厂的聚合根创建的情况下，将其添加到工厂的公共api中。
聚合根定义了事务边界，其中的数据应在事务上保持一致。对交易一致性的这种期望不应扩展到该范围之外的任何事物。如果您有一个依赖于另一个存储库的存储库，则您的一个聚合的状态在事务上依赖于另一个聚合的状态，这意味着这些“聚合根”都不是聚合根。
使用一个存储库使用另一个存储库不遵循DDD的原则。如果您需要来自一个聚合根的数据以对另一个聚合根执行某些操作，则可以检索第一个根（在应用程序服务层或可能在域服务中），然后将该数据传递到从属聚合根的公共api中，或者在使用单独工厂的聚合根创建的情况下，将其添加到工厂的公共api中。