Aggregates, Repositories and a service layer

Take a class which has relations with a couple of other classes. The first class can be seen as the aggregate(root). Seen from the point of the service layer how would one best split the calls?

1. Call the repositor开发者_开发技巧y of the aggregate for the entire object graph and call from that particular repository other repositories to handle the saving of the relations (one repository per type of class.
2. Call the repository of the aggregate for the entire object graph and handle all in that one method (so saving of all the relations in that same method).
3. From within the service layer, call the repositories for the aggregate and then directly after that, again from the service layer, call the repositories of the related classes.
4. Add an extra layer in between the service and the repositories and from within that extra layer do like in option 3.

I've seen already all 3 possible solutions in production code but I'm interested in the cleanest solution and a reason as to why one would opt for that approach.

For me it would be a choice between option 1 and 2 (I like to keep the "upper service layer" as simple as possible).

Which one of those I would choose would depend a bit on how the individual types of the aggregate are used; if they are always (at least currently) used as part of this one aggregate and not stand-alone, I would probably let the aggregate repository deal with them as well (but perhaps still in separate methods), but if the individual parts can also be used stand-alone (or as parts of other aggregates) I would probably lean towards having separate repository objects for them, and call into those repositories from the aggregate repository.