Implementando uma arquitetura limpa com Nest.JS

Este artigo é para entusiastas que se esforçam para escrever código limpo, escalável e, mais importante, refatorável. Isso dará uma ideia de como o Nest.JS pode nos ajudar a escrever um código limpo e qual arquitetura subjacente ele usa.

A implementação de uma arquitetura limpa com Nest.JS exigirá que primeiro compreendamos o que é essa estrutura e como ela funciona.

Nest ou Nest.JS é uma estrutura para criar aplicativos Node.js eficientes e escaláveis ​​(do lado do servidor) criados com TypeScript. Ele usa Express ou Fastify e permite um nível de abstração para permitir que os desenvolvedores usem uma ampla quantidade de módulos (de terceiros) dentro de seu código.

Vamos nos aprofundar no que é essa arquitetura limpa. 

Bem, todos vocês podem ter usado ou pelo menos ouvido falar da arquitetura MVC. MVC significa Model, View, Controller. A ideia por trás disso é separar nossa estrutura de projeto em 3 seções diferentes.

1. Modelo: Ele conterá o arquivo Object que mapeia com Relation/Documents no DB.

2. Controlador: Ele é o manipulador de solicitações e é responsável pela implementação da lógica de negócios e toda a manipulação de dados.

3. Visualize: Esta parte conterá arquivos relacionados à exibição dos dados, sejam arquivos HTML ou alguns arquivos do mecanismo de modelagem.

Para criar um modelo, precisamos de algum tipo de ferramenta/módulo/biblioteca ORM/ODM para construí-lo. Por exemplo, se você usar diretamente o módulo, digamos 'sequelize' e, em seguida, use o mesmo para implementar o login em seu controlador e tornar sua lógica de negócios principal dependente do 'sequelize'. Agora, no futuro, digamos que depois de 10 anos, há uma ferramenta melhor no mercado que você deseja usar, mas assim que você substituir sequelize por ela, você terá que alterar muitas linhas de código para evitar que ele quebra. Além disso, você terá que testar todos os recursos mais uma vez para verificar se foi implantado com sucesso ou não, o que também pode desperdiçar tempo e recursos valiosos. Para superar esse desafio, podemos usar o último princípio do SOLID que é o Princípio da Inversão de Dependência, e uma técnica chamada injeção de dependência para evitar essa bagunça.

Ainda confuso? Deixe-me explicar em detalhes.

Então, o que o Princípio de Inversão de Dependência diz em palavras simples é que você cria sua lógica de negócios principal e, em seguida, cria dependência em torno dela. Em outras palavras, libere sua lógica principal e regras de negócios de qualquer tipo de dependência e modifique as camadas externas de forma que elas dependam de sua lógica principal em vez de sua lógica depender disso. Isso é o que é arquitetura limpa. Ele remove a dependência de sua lógica de negócios principal e constrói o sistema em torno dela de tal forma que eles parecem ser dependentes dela, em vez de serem dependentes deles.

Vamos tentar entender isso com o diagrama abaixo.

Fonte: Cone de Arquitetura Limpa 

Você pode ver que dividimos nossa arquitetura em 4 camadas:

1. Entidades: Em sua essência, as entidades são os modelos (regras corporativas) que definem suas regras corporativas e informam sobre o que é o aplicativo. Essa camada dificilmente mudará com o tempo e geralmente é abstrata e não acessível diretamente. Por exemplo, cada aplicativo tem um 'usuário'. O que todos os campos que o usuário deve armazenar, seus tipos e relações com outras entidades comporão uma Entidade.

2. Casos de uso: Ele nos diz como podemos implementar as regras da empresa. Vamos pegar o exemplo do usuário novamente. Agora sabemos quais dados serão operados, o caso de uso nos diz como operar esses dados, como o usuário terá uma senha que precisa ser criptografada, o usuário precisa ser criado e a senha pode ser alterada a qualquer momento. determinado ponto de tempo, etc.

3. Controladores/Gateways: Esses são canais que nos ajudam a implementar os casos de uso usando ferramentas e bibliotecas externas usando injeção de dependência.

4. Ferramentas externas: Todas as ferramentas e bibliotecas que usamos para construir nossa lógica estarão nesta camada, por exemplo. ORM, Emailer, Criptografia, etc.

As ferramentas que usamos dependerão de como as canalizaremos para os casos de uso e, por sua vez, os casos de uso dependerão das entidades que são o núcleo do nosso negócio. Desta forma, invertemos a dependência de fora para dentro. Isso é o que implica o Princípio de Inversão de Dependência do SOLID.

Ok, agora você entendeu a essência do Nest.JS e entendeu como a arquitetura limpa funciona. Agora surge a pergunta, como esses dois estão relacionados?  

Vamos tentar entender quais são os 3 blocos de construção do Nest.JS e o que cada um deles faz.

1. Módulos: Nest.JS está estruturado de tal forma que podemos tratar cada recurso como um módulo. Por exemplo, qualquer coisa que esteja vinculada ao usuário, como modelos, controladores, DTOs, interfaces, etc., pode ser separada como um módulo. Um módulo tem um controlador e vários provedores que são funcionalidades injetáveis ​​como serviços, orm, emailer, etc.

2. Controladores: Os controladores no Nest.JS são interfaces entre a rede e sua lógica. Eles são usados ​​para lidar com solicitações e retornar respostas para o lado do cliente do aplicativo (por exemplo, chamar a API).

3. Prestadores (Serviços): Os provedores são serviços/funcionalidades injetáveis ​​que podemos injetar em controladores e outros provedores para fornecer flexibilidade e funcionalidade extra. Eles abstraem qualquer forma de complexidade e lógica.

Para resumir,

• Temos controladores que atuam como interfaces (3ª camada de arquitetura limpa)
• Temos provedores que podem ser injetados para fornecer funcionalidade (4ª camada de arquitetura limpa: DB, Devices, etc.)
• Também podemos criar serviços e repositórios para definir nosso caso de uso (2ª Camada)
• Podemos definir nossas entidades usando provedores de banco de dados (1ª camada)

Conclusão:

Nest.JS é um poderoso framework Node.JS e o mais conhecido texto datilografado disponível atualmente. Agora que você sabe tudo sobre esse framework, você deve estar se perguntando se podemos usá-lo para construir uma estrutura de projeto com uma arquitetura limpa. Bem, a resposta é sim! Absolutamente. Como? Vou explicar na próxima série deste artigo. 

Até lá, fique ligado!

Sobre o autor:

Junaid Bhat está atualmente trabalhando como líder de tecnologia no Mantra Labs. Ele é um entusiasta da tecnologia que se esforça para se tornar um engenheiro melhor todos os dias, seguindo os padrões do setor e alinhado a uma abordagem mais estruturada para a solução de problemas. 

Leia nosso último blog: Golang-Beego Framework e suas aplicações

Conhecimento que vale a pena ser entregue em sua caixa de entrada