Aviso
Arquitetura de Software é um tema bem teórico e de certa forma abstrato ~(ao menos para mim), então os tópicos abordados nesse artigo são a minha interpretação pessoal do conceito geral, sendo que essa interpretação é baseada na forma que utilizo esses conceitos em meus projetos.
Controller
O que é?
É uma das camadas da arquitetura MSC, responsável por fazer a recepção das requisições e passar adiante apenas as informações relevantes.
O que faz?
Como dito em sua definição, a camada de Controllers faz o "primeiro contato" com as requisições, enviando a camada de Services apenas as informações relevantes para completar a requisição. Além disso, essa é a camada que irá enviar a resposta ao cliente, seja ela positiva ou negativa.
Boas práticas
- Realizar apenas operações relacionadas a Request e Response (HTTP)
- Não possuir "conhecimento" sobre regras de negócios, ou acesso ao DB
- Formada quase que exclusivamente por Middlewares
Services
O que é?
É a camada intermediária da arquitetura MSC, responsável por abstrair as regras de negócio e controlar o acesso aos dados.
O que faz?
Como dito anteriormente, essa camada é responsável por guardar e abstrair as regras de negócio, para que a camada Model seja "leve" e objetiva. Sendo ainda responsável pelo acesso aos dados, validando se as informações recebidas da camada Controllers são suficientes para completar a requisição.
Boas práticas
- Centralizar o acesso aos dados e funções externas
- Abstrair regras de negócios
- Não ter nenhum "conhecimento" sobre a camada Model (EX: Query SQL)
- Não receber nada relacionada ao HTTP (Request ou Response)
Regras de Negócio
O que são?
São as validações que as aplicações devem fazer para que determinadas condições, normalmente definidas pelo cliente (pessoa), sejam atendidas.
Exemplos
- "O frete grátis só se aplica a compras acima de 100 reais."
- "Não deve ser possível criar um novo usuário com um email já cadastrado."
- "Só é possível acessar certo conteúdo caso a pessoa usuária seja assinante."
Dicas
Mantenha o Express longe
Uma boa ideia ao criarmos nossa API é definirmos LIMITES BEM CLAROS em relação "Até onde o Express vai", isso irá facilitar MUITO nosso trabalho caso optemos por trocar o Express por outro framework, pois será necessário refatorar apenas uma pequena parcela da API.
Uma sugestão de limite é em relação as rotas e middleware, ou seja, qualquer arquivo que fuja desse escopo não deve ter contato com o Express.
Organize suas pastas
Existem diversas formas de organizarmos nossos arquivos, cada um com suas vantagens e desvantagens, não precisamos escolher sempre a melhor, mas é importante definirmos uma lógica de organização e segui-la.
Mantenha sua configuração segura
Diferente das aplicações Front-End, as APIs no Back-End normalmente possuem diversas informações sensíveis que não devem estar públicas de forma alguma, ou seja, elas não podem estar "hard-codded".
Para resolver essa questão de segurança podemos utilizar variáveis de ambiente, essas que podem ser definidas via CLI, Docker ou o mais comum, arquivos .env.
Oldest comments (0)