Estruturando uma Aplicação Server-Side
Tags: webdev, programming, beginners, architecture
Published: 2022-06-20 12:01:19

## Introdução

E aí pessoal, depois de um hiato de dois anos sem escrever nenhum artigo, esse será o meu primeiro artigo pra voltar a escrever e tentar ajudar a comunidade de alguma forma.

Nesse artigo irei falar de como estruturar uma aplicação server-side de forma simples, mas com uma arquitetura limpa e eficiente para pequenas e grandes aplicações.

Esse será um artigo "teórico", não irei mostrar código e não estará ligado a uma linguagem específica, será uma abordagem no ponto de vista do design e arquitetura da aplicação, dessa forma vocês poderão utilizar em qualquer linguagem que conheçam.

Espero que esse artigo venha a ser útil para alguém!

## Era uma vez o MVC

Provavelmente vocês já devem ter ouvido falar do **famoso MVC**:

- M - Model (Modelo) - Camada de Dados
- V - View (Visualização) - Camada de Visualização
- C - Controller (Controlador) - Camada de Comunicação

Essa é uma arquitetura de software muito utilizada há alguns tempos atrás e provavelmente ainda usada hoje em dia para softwares mais simples.

Nessa arquitetura, temos três camadas distintas onde o acesso aos dados (Base de Dados) fica na **Camada de Dados**, que por sua vez é acessada pela **Camada de Comunicação** que é a camada responsável por receber os pedidos da **Camada de Visualização** onde o usuário interage com o software, fazer o processamento necessário e retornar a resposta novamente para a **Camada de Visualização**.

Essa é uma arquitetura simples e prática, porém com o avanço dos softwares que foram ficando mais complexos essa arquitetura começou a ficar um pouco obsoleta pelo acoplamento do código e as camadas foram ficando com muitas responsabilidades.

## Evoluindo a Arquitetura das Aplicações

Hoje em dia as aplicações Client-Side (Front-end) são tão complexas quanto as aplicações Server-Side (Back-end) e possuem arquiteturas e padrões para serem criadas de forma a suportar pequenas e simples, mas também grandes e complexas aplicações. Por isso a arquitetura **MVC** pode ser quebrada, tendo a **Camada de Visualização** se tornado uma aplicação com sua própria arquitetura. O foco desse artigo será a arquitetura da aplicação Server-Side.

Tirando a **Camada de Visualização** da nossa arquitetura, se fóssemos seguir a arquitetura **MVC** iríamos sobrar apenas com duas camadas: a **Camada de Dados** e a **Camada de Comunicação**, mas como eu disse anteriormente esse tipo de arquitetura resulta em um código muito acoplado, onde podemos ter duplicação de código e muitas responsabilidades em uma única camada.

## A Nova Arquitetura Server-Side

Se as duas camadas que falamos anteriormente não são suficientes para criar uma aplicação mais limpa e fácil de ser mantida, a solução é recriar a arquitetura da nossa aplicação server-side para que ela fique mais desacoplada e mais limpa.

Existem diversos livros, cursos e tutoriais falando sobre e também existem N tipos de arquitetura que são possíveis, aqui eu vou explicar apenas uma dessas arquiteturas, mas que funciona para mim e os projetos que tenho trabalhado nos últimos anos.

A arquitetura que venho utilizando é composta por quatro camadas:

- Camada de Comunicação
- Camada de Validação
- Camada de Serviço/Negócio
- Camada de Dados

Abaixo irei explicar resumidamente cada camada.

### Camada de Comunicação

Essa é a camada mais simples da aplicação e com menos responsabilidades, como o próprio nome diz, ela é a camada de comunicação entre o usuário e a lógica da nossa aplicação. Ela é responsável apenas pelo IO (Input & Output) da nossa aplicação, ou seja, essa aplicação recebe os dados enviados pelo usuário (pode ser através de uma ferramenta CLI ou uma página Web ou uma App de dispositivos móveis) e retorna o resultado de volta ao usuário depois de passar pelas outras camadas.

### Camada de Validação

Essa camada é responsável por validar os dados recebidos pela **Camada de Comunicação**. E se você está perguntando o motivo de separar essas duas camadas a resposta é simples. Imagine que hoje sua aplicação comunique com uma página Web e toda validação esteja acoplada com a requisição HTTP. Agora você ou sua empresa decidem criar uma ferramenta CLI para a aplicação. Estando sua lógica de validação acoplada com a requisição HTTP, você terá de recriar toda a lógica de validação novamente. Se você tivesse separado isso em uma camada específica, bastava recriar uma nova **Camada de Comunicação** que seria para a ferramenta CLI e toda sua aplicação estaria a funcionar normalmente.

### Camada de Serviço/Negócio

Essa é a camada mais importante da nossa aplicação, aqui é onde fica toda a lógica de negócio, todo o núcleo da aplicação. Essa camada é responsável por receber os dados já validados da **Camada de Validação**, buscar os dados necessários, aplicar a lógica necessária e formatar os dados de forma a enviar de volta para a **Camada de Comunicação**.

### Camada de Dados

Essa é a camada responsável por buscar e salvar os dados na(s) Base(s) de Dados da aplicação. Para se ter a separação da regra de negócio dos dados, essa deve ser a **ÚNICA** camada que faz acesso à(s) Base(s) de Dados, dessa forma se qualquer outra camada necessitar de acessar esses dados, deve ser feito através dessa camada.

## Conclusão

Com esse artigo aprendemos o que é a arquitetura **MVC**, os motivos dessa arquitetura estar obsoleta nos dias de hoje e vimos o exemplo de uma arquitetura para as aplicações Server-Side atuais que apesar de simples, é eficaz para se criar aplicações limpas e com código menos acoplado. Essa arquitetura pode ser aplicada em qualquer linguagem e não apenas para aplicações Web, como também APIs, CLIs, etc. 

Espero que esse artigo possa ajudar vocês a terem uma visão de como a arquitetura e o design da aplicação pode influenciar e MUITO no resultado final do software, para conseguir criar um software limpo e fácil de ser mantido e evoluído.