Eu sugeriria ter uma classe UserRepository
e UserFriendRepository
separadas. O UserFriendRepository pode pegar um User ou UserId em seu construtor.
(A menos que Usuários e Amigos sejam sempre tratados juntos e salvos juntos - então você desejaria apenas uma classe de repositório - mas não acho que esse seja o seu caso.)
A intenção do padrão Repositório é trazer uma camada de simplicidade, clareza (mais fácil para os desenvolvedores trabalharem com classes Usuário e Amigo do que classes de acesso a dados de baixo nível) e testabilidade de unidade. É uma camada de abstração onde, digamos, "cache" poderia ser adicionado (ou alterado ou removido) sem que o código do cliente soubesse.
Adendo com base no comentário:
Eu pessoalmente tive mais sorte em manter a camada Repositório simples (caso contrário, eu me re-implemento o ORM / ficando amarrado em nós). Eu prefiro chamar UserFriendRepo.Get () quando necessário e UserOrderRepo.Get () quando necessário; em vez de um repositório do usuário mais complexo que pode ser passado dicas para carregar [amigos] e [ordens].
No entanto, um repositório "mais inteligente" pode ser garantido se o carregamento rápido e / ou o carregamento lento ajudarem o desempenho de seu aplicativo específico, ou se ele for mais intuitivo para os desenvolvedores em sua loja etc. Padrões são apenas abordagens gerais que você está livre para afinar.