No final dos anos 1990, com a explosão de grandes aplicações corporativas em Java e .NET, tornou-se cada vez mais insustentável misturar lógica de negócio com SQL espalhado pela base de código. Padrões clássicos de Data Access Object (DAO) e Data Mapper já permitiam alguma separação, mas careciam de uma visão unificadora que tratasse o repositório de objetos como uma “coleção em memória”, escondendo por completo detalhes de persistência e queries complexas.

Em novembro de 2002, Martin Fowler formalizou essa visão em Patterns of Enterprise Application Architecture. Ele definiu o Repository como um intermediário entre a camada de domínio e o mapeamento de dados, que emula uma coleção de objetos e centraliza operações de CRUD e consultas declarativas através do uso de specifications ou expressões de filtro. No exemplo a seguir, uma versão simplificada do Generic Repository em .NET usando Entity Framework Core:

Menos de um ano depois, em agosto de 2003, Eric Evans popularizou o padrão dentro do contexto de Domain-Driven Design. Em seu livro Domain-Driven Design: Tackling Complexity in the Heart of Software, ele recomenda definir interfaces de repositório no próprio modelo de domínio, garantindo que toda lógica de recuperação e armazenamento de aggregates passe por pontos bem definidos. A implementação concreta fica na camada de infraestrutura, favorecendo testes unitários do domínio com mocks ou repositórios em memória:

Ao longo dos anos, o padrão evoluiu na prática dos frameworks. No ecossistema Java, o Spring Data JPA gera implementações de repositórios a partir de interfaces como CrudRepository<T, ID>, extraindo queries diretamente do nome dos métodos ou de anotações JPA. No .NET, surgiram abordagens genéricas de Generic Repository e Specification Pattern, muitas vezes combinadas com Dependency Injection para desacoplar ainda mais o acesso a dados.

Mais recentemente, em cenários de microsserviços, percebeu-se que repositórios monolíticos podem se tornar gargalos. Assim, adotou-se o CQRS, separando repositórios de escrita (que usam transações consistentes) de repositórios de leitura (otimizados para consultas rápidas), e o Event Sourcing, onde o repositório armazena eventos ao invés de estados. Em arquiteturas serverless e NoSQL, o pattern se adapta: repositórios deixam de ser coleções em memória tradicionais e passam a encapsular chamadas a APIs externas, caches distribuídos e até fluxos de eventos em Kafka.

Em suma, do esboço inicial de DAO e Data Mapper, passando pela formalização de Fowler e a incorporação de Evans no DDD, até as adaptações para frameworks modernos, o Repository Pattern cresceu de uma simples abstração de acesso a dados para um pilar flexível na construção de sistemas escaláveis, testáveis e alinhados aos domínios de negócio.

Referências

• Martin Fowler. Patterns of Enterprise Application Architecture (November 2002)
• Eric Evans. Domain-Driven Design: Tackling Complexity in the Heart of Software (August 2003)
• Exemplo de Repository + Unit of Work em Patterns of EAA (Java/C#)
• Spring Data JPA — CrudRepository e derivação de queries por nomes de método
• Evolução para CQRS e Event Sourcing em microsserviços