¶ Estudo para verificar viabilidade técnica para continuação do projeto E-estado
| Data de elaboração | 31/07/2024 |
|---|---|
| Responsável pelo estudo | Vinicius da Rosa Pereira |
| Equipe do estudo | Liderança Técnica |
| Alvo | Projetos NestJs do E-Estado |
| Origem | Implementação: Padrão de projeto a ser adequado para os projetos NestJS. |
| Objetivo | Padronizar os projetos NestJS. |
¶ 1. Introdução
Essa documentação tem como objetivo complementar a modelagem da documentação sobre a análise de risco dos projetos e-estado.
¶ 2. Desenvolvimento
Para possibilitar o desenvolvimento do diagrama abaixo, é necessário padronizar as camadas de Repository, Service, Controller e Module.
¶ 2.1 Repository
O Repository Pattern permite um encapsulamento da lógica de acesso a dados, impulsionando o uso da injeção de dependência e proporcionando uma visão mais orientada a objetos das interações.
Com o uso desse pattern, nossas entidades da camada de negócio, não devem sofrer impactos pela forma em que são persistidas no banco de dados.
Os grandes benefícios ao utilizar esse pattern são:
- Permitir a troca do banco de dados utilizado sem afetar o sistema como um todo.
- Código centralizado em um único ponto, evitando duplicidade.
- Facilita a implementação de testes unitários.
- Diminui o acoplamento entre classes.
- Padronização de códigos e serviços.
Antes de tudo, vamos definir nossa entidade de forma bem simples, conforme segue abaixo
Começamos pela implementação do repositório especializado. Vamos definir uma interface contendo algumas funções que deverão ser executadas, lembrando que essa interface atuará como uma fachada.
Implementamos a nossa interface, tornando obrigatória a implementação dos métodos existentes na interface.
¶ 2.2 Service
O Service é um conceito que visa abstrair regras de negócio das rotas, além de tornar nosso código mais reutilizável.
O padrão seguirá semelhante ao repositório, deverá implementar uma interface e posteriormente desenvolver a classe de serviço.
Desenvolvimento da interface:
Desenvolvimento da classe
A finalidade dos Services é separar as regras de negócio, aplicação e apresentação, permitindo que sejam facilmente testadas e reutilizadas em outras partes do programa.
¶ 2.3 Controller
A responsabilidade nesse sentido será muito simples, ela somente irá orquestra a chamada para a service.
¶ 2.3 Module
Um módulo é uma classe anotada com um @Module() decorador. O @Module() decorador fornece metadados que o Nest usa para organizar a estrutura do aplicativo.
Referência do site NestJS: Cada aplicativo tem pelo menos um módulo, um módulo raiz. O módulo raiz é o ponto de partida que o Nest usa para construir o gráfico do aplicativo - a estrutura de dados interna que o Nest usa para resolver relacionamentos e dependências de módulo e provedor. Embora aplicativos muito pequenos possam teoricamente ter apenas o módulo raiz, esse não é o caso típico. Queremos enfatizar que os módulos são fortemente recomendados como uma maneira eficaz de organizar seus componentes. Assim, para a maioria dos aplicativos, a arquitetura resultante empregará vários módulos, cada um encapsulando um conjunto intimamente relacionado às capacidades.
Segue o desenvolvimento do Module:
¶ 3. Conclusão
A implementação do padrão deve ser gradativa, pois se trata de um projeto existente. Essa abordagem permite a adaptação cuidadosa ao novo padrão, minimizando interrupções e garantindo a continuidade das operações enquanto as mudanças são introduzidas de maneira controlada e eficaz. Além disso, uma implementação gradual facilita a identificação e resolução de possíveis problemas, assegurando uma transição mais suave e bem-sucedida para o novo padrão.