Controller e Service - Uma breve introdução
Tags: beginners, node, architecture, braziliandevs
Published: 2022-03-25 21:16:32

## 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`.