Daniel, leia o livro e tire suas conclusões. Mais de uma vez no GUJ os conceitos de Repository e outros padrões de Domain-Driven Design foram descritos como se fosse a maneira "certa"e um pequeno quote de um livro desmentiu isso. O livro em questão sequer fala em interfaces, qualquer conclusão do que é certo ou errado, seja lá o que isso signifique, é feita por alguém que não Eric Evans.
Na verdade, o livro não diz sequer como o Repositório interage com a base de dados. Ele cita alternativas mas na descrição mostra o Repositório interagindo diretamente com a base de dados. Porque isso? por que usar Repositorio não implica em usar DataMapper/DAO. Segundo o livro você deve adaptar o padrão (aliás, todos os padrões) à sua relidade tecnológica. Evans cita o uso de Entity Beans (EJB 2.x) como Aggregate Roots, por exemplo.
Um repositório é um conceito, como você modela o conceito depende da linguagem/plataforma em questão.
E Orientação a Objetos básica não fala de interfaces, interfaces existem apenas em algumas linguagens. Quando alguém depende de uma interface ele depende de algo que se comporta de uma maneira X, não importa quem. Suponha que você tenha uma interface:
interface A{
void a1(String asdf);
String a2()
}E uma classe:
class B{
public void a1(String asdf){/* ... */ }
public String a2(){/* ... */ }
}É mais que claro que a classe B obedece o contrato exposto em A, logo não há porque criar uma classe C:
class C implements A{
B b;
public void a1(String asdf){b.a1(asdf); }
public String a2(){ return b.a2();}
}Isso não é sequer purismo, é desconhecimento sobre o que é uma interface e onde ela encaixa no paradigma e, principalmente, sobre Domain-Driven Design.
Claro que se o repositório contiver regras você usará uma classe numa linguagem como Java, o que eu ainda não vi foi um motivo para um Repositório ter regras de negócio. É uma possibilidade, pode acontecer, mas eu nunca vi.