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.
Top comments (4)
Wendell, acha uma feature possível da aplicação que não necessáriamente faz parte do domínio dela como autenticação e autorização (acho que se isso faz ou não parte do domínio também é outro debate que pode ser aprofundado), mas que podem vir a possuir tanto Entidades, Serviços, Repositórios, Filtros e etc dedicados exclusivamente pra ela justificam a criação de uma nova camada? Dentro do conceito de microsserviços isso adquire outro aspecto pois geralmente a segurança é manipulada em um microsserviço exclusivo, mas no caso de um monolito, por exemplo, não iria criar um nivel de complexidade maior misturar features de interesse do domínio com features externas a esse domínio?
Além dessa arquitetura de camadas, quando trabalho em um monolito eu divido a aplicação em módulos (é o que fazemos na empresa que trabalho atualmente). Então temos um módulo dedicado para autenticação e autorização.
Nesse caso fazemos isso no monolito para separar as responsabilidades de cada módulo, deixar a arquitetura e o código mais limpo e reutilizável e também para facilitar a manutenção.
Pense nos módulos como um agrupamento de microserviços, porém todos na mesma base de código.
A arquitetura que usamos na API da empresa que trabalho atualmente é baseada nesse projeto Open Source meu: github.com/WendellAdriel/larapi. Mesmo que tu não trabalhe com PHP, dando uma olhada nesse repo acho que tu vai entender como é essa separação por módulos que expliquei!
Valeu por puxar esse assunto pois é algo MUITO VÁLIDO de se falar e discutir quando falmaos de arquitetura de aplicações!
Achei muito maneira essa solução de módulos dentro de um monolíto. Mesmo tendo um monolito relativamente grande, muitos projetos ficam nesse meio termo de não ter necessidade de microsserviço, mas ao mesmo tempo não caber dentro de um monolíto. É uma solução bem interessante.
Tem dado certo na empresa que trabalho, e é um SaaS complexo e grande! A base da nossa API é nesse repo/projeto que eu criei que enviei no outro comentário! Acho legal que tenha gostado dessa solução! Eu tenho usado também em projetos pessoais e alguns freelas essa solução e até o momento me atende bem!