Migração de dados usando Clean Architecture
Migrar significa mudar algo ou alguém de um lado para outro. Em engenharia de software, por vezes se torna necessário migrar de uma arquitetura para outra, ou até mesmo, de uma fonte de dados para outra. Estes processos acontecem muito em áreas como por exemplo Business Intelligence (BI), Big Data ou até mesmo em outros contextos como mudar de uma base de dados relacional para uma base de dados não relacional. Isto pode acontecer por exemplo, quando se pretende migrar a solução on-premise para um ambiente cloud. Um bom design de sistemas torna-se necessário na questão de migrar dados. A arquitetura de sistema deve estar preparada para trocar um componente pelo o outro. É aqui que entra a Clean Architecture.
O que é Clean Architecture?
A 13 de agosto de 2012, Robert C. Martin, mais conhecido como Uncle Bob, desenvolveu o conceito de Clean Architecture (Clean Coder Blog). Este é mais um padrão em que sua filosofia é a separação de responsabilidades através da divisão do sistema em camadas independentes de qual framework estamos a usar, qual base de dados escolhemos ou se estamos a usar React ou Angular. Neste conceito, o que importa é a presença de uma interface que implemente o que está externo ao sistema, desde que esta interface seja respeitada, qualquer tecnologia ou componente externo pode ser utilizado. Desta maneira, a atualização de uma biblioteca para uma versão mais recente só terá de respeitar a interface definida.
Caso de estudo: Migração de uma base de dados relacional para uma base de dados não relacional
Tal como explicado na introdução deste artigo, por vezes uma empresa necessita de migrar dados de uma base de dados relacional para uma base de dados não relacional, por exemplo, num cenário de computação na cloud. E porquê fazer isto?
As base de dados NoSQL (...) proporcionam uma migração tranquila de base de dados para a nuvem (Microsoft, 2024) As base de dados NoSQL são escaláveis horizontalmente o que torna mais barato escalar horizontalmente do que verticalmente isto é, adicionar mais um núcleo ou mais memória RAM ao nosso servidor(escalabilidade vertical) ou adicionar mais uma réplica ao cluster (escalabilidade horizontal)
No entanto, por vezes o nosso sistema fica totalmente acoplado à base de dados que nós escolhemos e um dia que queirámos realizar este processo de migração, isto será muito complicado pois estaremos a mudar 1000 linhas de código e é aqui que a Clean Architecture ajuda devido ao seu princípio de desacoplamento entre o que é externo como por exemplo as base de dados.
Considere um pequeno sistema que regista um utilizador numa base de dados relacional modelado com Clean Architecture(ProgramandoComAndre/notes (github.com):
Este sistema é desacoplado da base de dados. Este sistema está incompleto, mas o que se pretende mostrar não é o sistema a funcionar mas sim o conceito de migrar dados de um lado para outro.
Neste sistema é utilizado um ORM (Sequelize) para bases de dados relacionais. Este suporta diversos drivers como o tedious par SQL Server, o mysql para MySQL, o pg para PostgreSQL. Para mostrar que o sistema funciona, na imagem seguinte encontra-se screenshots tanto da API como do DBMS:
No ficheiro index.ts substituiu-se a dependência do Sequelize pelo mongoose:
O objetivo é migrar esta base de dados para o MongoDB. Como fazer isto?
No código do repositório anterior, encontra-se uma interface chamada UserRepository:
Esta interface é o ponto chave desta situação, porque agora é possível implementar uma classe concreta para MongoDB.
Para este teste, será utilizada a biblioteca mongoose que é um ODM para MongoDB. Implementou-se a classe MongooseUserRepository. Essa classe usa um modelo do mongoose criado com os mesmos campos da base de dados SQL.
A única diferença é a propriedade _id que usa UUID definido pela aplicação.
Depois, criou-se a classe MongooseUserRepository:
Realizou-se um teste à API e percebeu-se que o utilizador foi registado com sucesso retornando 200 OK:
Na imagem seguinte encontram-se os dados registados na base de dados através da interface do MongoDB Compass:
Pode-se perceber que o efeito que queríamos resultou e desta forma comprova-se a facilidade de migrar dados do SQL para o NoSQL. Concluindo, é possível perceber que apenas foi necessário mudar uma ou duas linhas de código.
A segunda parte da migração de dados passa por um procedimento de ETL(Extract Transform Load) que não será demonstrado aqui. Poderia-se utilizar um sistema de integração de dados como o Pentaho Kettle para esta migração e desnormalizar as tabelas de forma a ser possível obedecer ao esquema de documento. E os dados estariam na nova base de dados como antes.
O objetivo deste artigo foi comprovar a facilidade de migrar de uma base de dados para outra utilizando padrões de projeto como a Clean Architecture dando o contexto de computação na cloud.
Bibliografia:
Microsoft. (2024). Base de dados nosql – O que É nosql?. Microsoft Azure. https://azure.microsoft.com/pt-pt/resources/cloud-computing-dictionary/what-is-nosql-database