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.