Contextualizando o uso do padrão Repostório (Repository)
Motivação
Em março postei um artigo sobre decomposição de software onde apresentei brevemente várias abordagens de decomposição de software com uma pequena contextualização. Dentre elas falei brevemente do padrão de projeto Repositório (Repository). Vou mostrar como esse padrão pode ser útil criando dando flexibilidade do ponto de vista de técnico e maior agilidade do ponto de vista estratégico de negócio.
Neste artigo vou apresentar este padrão como uma ferramenta de agilidade e transformação digital. Para isso vamos avaliar o padrão dos pontos de vistas:
- Técnico Estratégico;
- Estratégico de negócio.
Respotiory Visão Técnico Estratégica
Uma visão do padrão seria o da imagem abaixo, onde ele é usado para generalizar, ou ocultar os detalhes de implementação do acesso aos dados de base de dados diferentes. Aqui cabe uma observação, apesar deste padrão ser amplamente usado em poucos casos eu vi acessando dados que não fossem relacionais.
Considerando o uso do Repositório como camada de abstração para mapeamento e acesso a dados, a imagem mostrar 3 possibilidades de mapeamentos, relacional, documento e grafo, cada com sua características sendo utilizados pela aplicação de forma transparente.
Considero esse um padrão estratégico, pois segundo o próprio Martin Fowler no livro Patterns of Enterprise Application Architecture o padrão repositório é útil para sistemas com bases de dados com múltiplos esquemas ou múltiplas fontes.
...it can be especially useful in systems with multiple database schemas or sources for domain objects
Martin Fowler
Ele se utiliza dois outros padrões um de mapeamento o Object Relational Mapping (ORM) e Query Object (QO). O primeiro utilizado para mapear as fontes de dados e objetos de negócio, o segundo usado para selecionar objetos com base em critérios.
Diversos provedores de tecnologia disponibilizam frameworks implementando esses padrões, como: Hibernate, Entity, etc.
O uso do padrão repositório dá independência da fonte de dados, mas o problema é que a maioria dos provedores apenas disponibilizam mapeamentos para bases relacionais.
Na proposta original do padrão nome seria Metadata Mapping, ou seja mapeamento de metadados sendo o mapeamento objeto relacional sendo apenas uma aplicação.
Existem frameworks excelentes como django web, que já disponibiliza uma camada de mapeamento assim para bases relacionais. O Spring-data é uma maravilha que na data desse artigo possui suporte a mais de 20 bancos de dados, do ponto vista técnico estratégico como é possível expandir o uso do padrão ao seu máximo potencial.
Aplicação Multimodelo com o Padrão Repositório
Atualmente já é comum o uso de "cache" através bases No-sql com dados processados e replicados, isso pode ser trabalhado de duas maneiras:
- Transformação dos dados em paralelo a aplicação;
- Transformação dos dados integrada a aplicação.
Transformação dos dados em paralelo a aplicação
Essa abordagem te leva a tomar uma séria de decisões acerca do cache, pois uma vez que ele não está integrado ao fluxo de informações ele precisa ser gerenciado com atualizações e invalidações de dados, bem como seu tamanho.
Provedores com a Microsoft publicaram guias de boas práticas apresentando diversas técnicas de Caching, pessoalmente eu sempre considero "o custo de cada vantagem" em todas as camadas das aplicações que desenvolvo, como exemplo: A cor verde representa os cache nativos das plataformas ou serviços, como navegador e web servidor. A cor vermelha é gerenciado pelo devenvolvedor.
O grau de complexidade ao distribuir o cache por toda a aplicação é elevado. Pois o padrão repositório acaba sendo substituído por essa infraestrutura muito mais complexa, que adapta adapta a arquitetura como um todo. Essas modificações seriam desnecessárias fazendo alterações apenas nas camadas de acesos a dados.
Por isso, acho importante avaliar nossa camada de dados a todos tempo, ela pode não necessitar de escalabilidade no início mas, vale a pena olhar a camada de dados sob a pena de elevar o grau de complexidade da solução como um todo.
Transformação dos dados integrada a aplicação
Nessa segunda abordagem estende a solução para consumo de dados processados por processos de ETL. A imagem abaixo mostra uma aplicação ou serviço que implementa duas versões do padrão Repositório, uma interage com mapeamentos relacionais outra com mapeamentos de estruturas No-SQL. Essa pode ser uma abordagem simples e interessante pois essas estruturas são alimentadas por processos de ETL que podem ser integrados a aplicação ou acionados por um time externo normalmente de análise de dados.
Essa foi uma espécie de contextualização técnica do padrão repositório conforme discutido no livro Patterns of Enterprise Application Architecture, nos diagramas eu considerei visão conceituais que se aplicação diversos desenhos arquiteturais na linha Stateless, ou seja as base de dados estão externas as aplicações e são compartilhadas.
Esse é o primeiro artigo da série sobre o uso do padrão repositório como forma e agilizar seu processo de desenvolvimento abrindo a possibilidade de uso do padrão Repositório provendo acesso a dados já processados e otimizados para consultas, usualmente em relatórios mas que também podem ser consumido por aplicações.
Créditos
Photo by AbsolutVision on [Unsplash])
Artigos Relacionados
Sobre o Autor
Profissional de tecnologia, agilista atuando no mercado a mais de 20 anos em diversas áreas. Nos últimos 5 anos venho trabalhando especificamente com pesquisa, desenvolvimento e inovação em diversos setores da indústria brasileira e internacional sempre utilizando conceitos e ou tecnologia de ponta. Há 19 anos eu era um novato em tecnologia e já havia criado meu primeiro portal para compartilhar informações de qualidade em língua portuguesa, o http://www.geleira.org. Acho que agora é o momento de voltar fazer isso e compartilhar o que aprendi nesses quase 20 anos de carreira.
0 Comentários