If repositories are for aggregate roots, where should data access logic for other entities go?

I have a few objects that represent a web application. Currently I have a cluster object to represent a specific deployment of the app. Within a cluster object I have the following objects: Server, Customer, User. None of these objects can exist without being part of a cluster, so I created a ClusterRepository to retrieve the clusters from the database. Now, from the cluster I need to get a list of Customers, presumably by using a method in the Cluster object like 开发者_StackOverflow社区GetCustomers(). Now, my initial thought was to then offload the work of this operation to a CustomerRepository, but since repositories are only for aggregate roots, where should the data access logic go? Does this belong in a service class?

---

Essentially, an Aggregate root is any object that you might need to fetch as the root of an object graph. Just because a specific entity is an aggregate root, and has a repository, does not mean that another entity which is one of it's properties can't also be an aggregate root - with it's own repository.

A good example is a customer billing system. Customer would certainly be an aggregate root, and would contain a collection of invoices... But for another application function, the invoice itself might be an aggregate root with constituent LineItem objects in it's object graph.

So in your example, there is nothing wrong with creating another repository for customers, if you need to fetch them independantly of clusters in some situations.

NOTE: See thread in comments as well. Although root entities can, (and often will) have references to other root entities, it is frowned upon (and that may be too mild a turn of phrase) to allow the repository for any root entity to contain functionality that manages (creates, updates, or deletes) any root entity within its object graph that it has a reference to. Any such referenced root entities should have their own individual repositories, and the functionality to manage them (Create, Update and/or delete operations) should be in their repository, so that it is only in one place.