Este post é o começo de uma série. Nela, vou abordar a arquitetura de software que os Frameworks fazem você aplicar.
Se você conhece Robert Martin, já leu algum livro ou já assistiu palestras dele, com certeza já ouviu ele falando muito mal de Frameworks no geral e como eles impedem a criação de um sistema livre de acoplamento nas camadas mais internas do software.
Um dos exemplos que ele dá quando está falando do assunto é a famosa anotação @Autowired do Spring espalhada pelo código todo, criando dependências de classes pertencentes ao domínio com o framework - o que, como especificado em Clean Architecture é algo definitivamente algo que não deve ser feito.
É quase que possível chamá-lo de inimigo dos Frameworks. Brincadeiras a parte, a lição que ele quer passar é para não usar o Framework indiscriminadamente, pois o Framework não conhece o problema que você está tentando resolver. Ele dá um caminho, mas esse caminho pode não estar alinhado com o seu, e cabe a você por os limites de onde usar o Framework e onde não usar. Se soubermos em qual camada aplicá-lo, podemos manter nosso domínio independente de agentes externos e mudanças de versões.
Minha ideia é desmistificar algo que quando comecei era nebuloso para mim. Uma coisa que temos que ter em mente é que todo Framework também é um software. Esse framework que veio a sua mente agora também usa algum tipo de arquitetura e inerentemente, meio que te obriga a seguir por um caminho que caso você não siga, vai encontrar dificuldades ou no mínimo não será tão fácil quanto se apenas seguisse a documentação dele.
Frameworks assim são chamados de 'opinionated frameworks' ou 'frameworks enviesados'. Veja o Angular. Ele até te oferece uma CLI para gerar recursos e boilerplate automaticamente para você só implementar sua lógica. Mas isso vem com o custo de seguir a risca a arquitetura fornecida pelo framework - é possível não seguir exatamente a risca, mas não vamos entrar no mérito hoje.
Diferentemente do React no extremo oposto - que não necessariamente é um Framework, muitos o consideram como apenas uma biblioteca. React te permite fazer o que quiser e aplicar a arquitetura que quiser. Porém, com o custo de você precisar e estar bem ciente do que está fazendo. Caso contrário, em pouco tempo você perde o controle da solução e começam a surgir incongruências no seu código difíceis de analisar e mais complexas para refatorar.
Deixando bem claro que Frameworks não enviesados não são melhores nem piores do que os enviesados. Cada um tem seu ponto positivo e negativo, e basta analisar sua situação para descobrir qual se encaixa melhor para resolver o seu problema.
Numa equipe grande é mais fácil gerenciar o padrão de código usando um framework enviesado, pois o padrão a ser implementado é o do próprio framework, basta segui-lo. E de novo, cada caso é um caso.
O primeiro framework que vou abordar nessa série foi inclusive inspirado no Angular para ser feito, e tem ganhado notoriedade por sua dita rapidez de desenvolvimento, pelo fato de também contar com uma CLI que gera os códigos e boilerplate para você e de quebra, toda a estrutura de pastas e módulos. Percebe-se que este é um framework enviesado.
Mas qual é esse enviesamento? Que arquitetura ele te faz usar?
O Nestjs usa Vertical Slice Architecture.
Essa abordagem está muito perto da ideia de casos de uso, eu diria que ela praticamente nasceu para trabalhar com casos de uso. Vertical Slice é visto como uma alternativa a complexidade de código e entendimento necessário para ser possível aplicar a Clean Architecture.
O Nest.js claramente tem o viés de trabalhar com recursos e casos de uso. E ele usa essa abordagem da Vertical Slice Architecture para te ajudar a desenvolver.
Podemos ver o resultado de usar a CLI dele para gerar um recurso através do comando: nest generate resource
Perceba que tudo está em um só lugar.
O Controller que lida com requisições HTTP, o Service que lida com regras de negócio, Repository para armazenamento dos dados, Entities, DTOs, Exceptions estão todas juntas.
A ideia é que tudo que for relativo a essa entidade seja resolvido dentro desta pasta. O Nest.js também te fornece a injeção de dependências aonde for necessário.
Fazendo um paralelo com Clean Architecture, estamos ferindo alguns princípios como o isolamento da camada de domínio com o framework e também como colocando no mesmo nível as entidades com o responsável pela comunicação HTTP.
Uma arquitetura ferir os princípios da outra não quer dizer que é uma arquitetura ruim. Cada arquitetura tem um objetivo. O objetivo da Vertical Slice Architecture é resolver um problema e a solução que ela dá é essa.
O fato de tudo isso estar na mesma pasta, não necessariamente vai de desencontro com a Clean Architecture. A ideia da CA é a direção das dependências. Mas algo que o autor cita é que ao olharmos para um projeto, devemos bater o olho e saber sobre o que o projeto trata e não, qual framework está sendo utilizado baseado na estrutura de pastas.
O objetivo do Nest.js é bem claro. Na página inicial vemos a seguinte frase "A progressive Node.js framework for building efficient, reliable and scalable server-side applications."
A forma que o autor do Nest.js achou melhor para atingir estes objetivos foi fazer você usar a Vertical Slice Architecture.
E você? Qual sua visão desse ângulo sobre os Frameworks?
Já bebeu sua água hoje?