O que eu amo na camada de acesso a dados (DAL) ao criar pequenos projetos de back-end

A camada de acesso a dados (DAL) é um conceito que existe há anos. Depois de brincar com o conceito por vários meses, achei que seria o momento perfeito para compartilhar meus pensamentos e também como abstraí o DAL
para meus pequenos projetos (com vários microsserviços de back-end) usando uma biblioteca comum de acesso a dados :)
Observe que meus microsserviços de back-end foram desenvolvidos usando Spring Boot.
Para que serve a camada de acesso a dados (DAL)?

A ideia principal do DAL
é para abstração. É uma camada responsável por gerenciar o armazenamento de dados (por exemplo, criar, ler, atualizar, excluir). Algumas das razões para implementar um DAL
incluem:
- Forneça a flexibilidade para substituir o banco de dados/fonte de dados subjacente. Por exemplo. mudando de MySQL para MongoDB.
- Abstraia e separe a lógica de acesso a dados da lógica de negócios, permitindo que ambas as camadas evoluam de forma independente.
- Encapsular dados para permitir que qualquer microsserviço interaja com os dados
Apresentando a Biblioteca de acesso a dados
É possível implementar os DAL
conceitos dentro da base de código do seu microsserviço. No entanto, se você estiver trabalhando com vários microsserviços, convém abstrair DAL
ainda mais implementando uma biblioteca externa comum de acesso a dados.
Uma biblioteca de acesso a dados é uma biblioteca externa personalizada que contém toda a lógica de acesso a dados (operações AKA CRUD).

Isenção de responsabilidade: este é um antipadrão para a arquitetura de microsserviços. Seguindo o padrão de arquitetura de microsserviço (responsabilidade única e baixo acoplamento), cada microsserviço deve ter seu próprio banco de dados e, portanto, nenhuma biblioteca de acesso a dados compartilhados.
No entanto, nem todos podem se dar ao luxo de ter um banco de dados por microsserviço devido ao custo e ao esforço de manutenção. Isso é especialmente verdadeiro quando você está migrando da arquitetura monolítica para microsserviço ou quando tem um projeto muito pequeno.
Neste artigo, estou focando principalmente em pequenos projetos. Portanto, usarei um único banco de dados compartilhado para todos os meus dados persistentes de microsserviço. Para projetos com um banco de dados compartilhado, você pode ter uma biblioteca comum de acesso a dados compartilhados ou agrupar a biblioteca de acesso a dados por recursos.
Opção A: Biblioteca de acesso a dados compartilhados

Ter uma biblioteca externa compartilhada de acesso a dados é particularmente útil quando você tem um projeto pequeno, pois permite centralizar toda a sua lógica de acesso a dados em uma única biblioteca. A principal vantagem é que você só precisará manter e modificar uma única biblioteca, enquanto a desvantagem é que a biblioteca compartilhada terá lógica redundante para todos os seus microsserviços.
Além disso, uma coisa que você deve considerar é o controle de versão da biblioteca.
- Se você publicar sua biblioteca, precisará de uma maneira de verificar todos os seus microsserviços que estão usando a biblioteca sempre que atualizar a biblioteca.
- Se você emparelhá-lo com o Monorepo, não precisará se preocupar com o controle de versão, pois seus casos de teste informarão quais microsserviços são afetados pelas modificações da biblioteca.

Para evitar muita lógica redundante na biblioteca de acesso a dados, em vez de ter uma única biblioteca de acesso a dados compartilhada para todos os seus microsserviços, você pode criar várias bibliotecas de acesso a dados e agrupá-las por recursos. Isso depende muito do tamanho do seu projeto, bem como de quantas pessoas estão trabalhando no projeto.
No entanto, observe que ter muitas bibliotecas de acesso a dados também pode apresentar dificuldades em mantê-las. Quando isso ocorrer, você deve repensar toda a sua arquitetura de microsserviço.
Como implementar a biblioteca de acesso a dados
Esteja você usando uma biblioteca de acesso a dados comuns compartilhada ou uma biblioteca de acesso a vários dados, as etapas para implementar uma biblioteca externa são as mesmas. Para implementar a biblioteca de acesso a dados, precisaremos criar uma biblioteca com os seguintes componentes.
#1 — Objeto de Transferência de Dados (DTO) e Entidade
O padrão Data Transfer Object (DTO) é um padrão de design que nos permite desacoplar a camada de acesso a dados (DAL) e a camada de serviço de negócios conforme ilustrado abaixo.

O DTO
atua como um contrato para transferência de dados entre o cliente (camada de negócios) e a biblioteca (camada de acesso a dados), mas não o interior da biblioteca. Como o cliente só interage usando o DTO
, isso nos permite ter maior flexibilidade para modificar as partes internas da biblioteca sem afetar o cliente desde que o DTO
não mude.
Observação: você pode pensar em DTO
como um objeto que transfere dados entre a camada de negócios e a camada de dados, enquanto o Entity
é um objeto que representa o esquema/tabela do banco de dados. O mapper
atua como uma ponte para converter entre DTO
e Entity
vice-versa.
#2 — Objeto de Acesso a Dados (DAO)
O padrão Data Access Object (DAO) é um padrão de design que fornece uma interface abstrata para interagir com o banco de dados. O DTO
padrão lida com a transferência de dados enquanto o DAO
padrão lida com a lógica CRUD.

O DAO
encapsula a lógica de acesso a dados para os requisitos de negócios do microsserviço. Isso nos permite alternar facilmente a lógica de acesso aos dados subjacentes sem afetar a lógica de negócios (por exemplo, alterações de banco de dados/esquema/lógica).
Observação: você pode pensar nisso DAO
como uma interface com a lógica CRUD. Por exemplo. criar um novo usuário, atualizar as informações do usuário, excluir um usuário, etc…
No entanto, é importante não complicar a DAO
lógica de negócios complexa, pois é melhor deixá-la na camada de negócios.
#3 — Teste de Integração
Existem 2 tipos de teste de integração que devem ser escritos aqui.
- Teste de integração com o banco de dados — Serve para testar se toda a lógica DAO funciona com o banco de dados. Por exemplo. Aumentando a versão do banco de dados.
- Teste de integração entre o microsserviço e a biblioteca de acesso a dados — Isso nos permite identificar rapidamente quaisquer alterações afetadas quando a biblioteca de acesso a dados é atualizada.
Conclusão — A Biblioteca de Acesso a Dados é uma boa ideia?
Realmente depende! Eu o recomendaria se você estiver trabalhando em projetos pequenos. Na maioria das vezes, você não criaria um banco de dados por microsserviço desde o início. Em vez disso, você provavelmente terá um único banco de dados compartilhado devido ao custo e à simplicidade.
Nesses casos, ter uma biblioteca comum de acesso a dados (com DAL
conceitos aplicados) que possa ser usada em vários microsserviços é muito útil, pois fornece uma boa camada de abstração para manutenção do código. Também é muito conveniente, pois você só precisa gerenciar uma única biblioteca de acesso a dados compartilhados para todas as operações relacionadas ao banco de dados. Além disso, melhora a legibilidade do código e incentiva os desenvolvedores/engenheiros a escrever testes de integração. No entanto, observe que, como é uma biblioteca de acesso a dados comum, a biblioteca de acesso a dados será inflada com muitos códigos redundantes.
Nota: Mesmo se você não estiver usando um banco de dados compartilhado, ainda poderá aplicar os conceitos da camada de acesso a dados ou até mesmo abstrair a lógica em uma biblioteca de acesso a dados.
É isso! Este é um resumo do que aprendi e apliquei que escrevi no contexto de pequenos projetos com bancos de dados compartilhados. Definitivamente, não é algo que pode ser aplicado a tudo, especialmente quando o banco de dados compartilhado e a biblioteca de acesso a dados compartilhados introduzem acoplamento à sua arquitetura. Dito isso, espero que este artigo seja útil para todos os novos desenvolvedores/engenheiros aprenderem mais sobre os DAL
conceitos.
Se você gostou deste artigo, por favor, siga-me para mais! Darei continuidade a este artigo com um exemplo de como implementar e testar a biblioteca de acesso a dados no Spring Boot.
Obrigado por ler :)
Codificação de nível
Obrigado por fazer parte da nossa comunidade! Antes de você ir:
- Bata palmas para a história e siga o autor
- Veja mais conteúdo na publicação Level Up Coding
- Curso gratuito de entrevista de codificação ⇒ Veja o curso
- Siga-nos: Twitter | Linkedin | Boletim de Notícias