Is it generally acceptable that one repository can access another repository? Specifically in this case, I have one aggregate root that uses another aggregate root to determine what entities to add. It falls along the lines of an Item/Item Type relationship. The reason that the Item Type is an aggregate root is that they are separately maintainable within a management tool outside of the scope of any single Item.
If it does matter, I am only creating my repository instances through a repository factory implementation, so I am not directly creating it by the concrete class name. At no time is the aggregate aware of the repository.
Edit – More information:
The specific implementation is that we can attach images to a document. Not only can we manage the images on the document, but there are different types of images (types being defined as how it is implemented, as opposed to an extension, for example). The document aggregate is one of a few types of other objects in the system that use these images and they do not all use the same types. While we do attach rules in the domain services, this is more specifically geared towards building the document aggregate. When building the aggregate we have five images of a specific type, and one each of two other types. We pull these individually because they are stored in separate lists in the aggregate. The validation is not the issue, but limiting what type of images are being evaluated when assembling the document.
I guess it boils down to what your trying to do. If it’s a sort of validation step (e.g. remove all items that have item types that have expired) you could argue it belongs in a service layer or specification. From the language you use (i.e. “determine what entities to add”) it seems to suggest the latter, though it’s hard to say without more details.
I guess from a certain point of view there’s no real reason why you can’t (I’m by no means a super DDD purest), especially since an Item and its type could be viewed as an aggregate root and it’s only the implementation detail that you need to provide a management console that’s prevent.
From another point of view it does seem to suggest that there’s a blurring between your aggregate roots that could suggest two different contexts are at work. For instance, one could argue that a management tool forms a separate bounded context to your main application and therefore the case for the Item type being an aggregate root does not really apply. e.g. The management tool might only ever be concerned with Item Types (and never items) while your main application might view item types as more of a value object than an entity.
Update
As you mention assembling the document this seems like the responsibility of a factory class that can correctly assemble a valid entity (the factory can use the image type repository). A repository should (in my eyes) expose querying and adding operations, not the logic to configure entities (except maybe rehydrating from persistence).