MVC

Escolher a arquitetura errada pode arruinar um projeto, ainda mais em um projeto de crescimento desgovernado. 

Antes de escrever a primeira linha, toda aplicação já carrega uma decisão silenciosa: como as peças vão se encaixar. Essa decisão define se o sistema vai escalar com facilidade ou virar um pesadelo de manutenção lá na frente.

Este post não substitui a literatura, e nem é essa a intenção. Mas se ele te der um norte, já cumpriu o papel.

Antes de entrar em cada uma, vale alinhar uma coisa: não existe arquitetura certa ou errada... existe a mais adequada para o contexto. 

Com isso em mente, vamos ao que importa!

 

 A arquitetura monolítica é o ponto de partida de boa parte dos sistemas. Interface, regras de negócio e dados vivem juntos, em um único lugar. É a escolha natural para projetos pequenos e MVPs, onde a prioridade é validar rápido.

A arquitetura em camadas divide a aplicação em responsabilidades empilhadas: apresentação conversa com negócio, que conversa com dados. Cada camada conhece apenas a que está abaixo dela. Provavelmente você já trabalhou com ela sem saber.

O MVC divide a aplicação em três partes: Model cuida dos dados e regras, View é o que o usuário vê, e Controller faz a ponte entre os dois. É o primeiro padrão que a maioria dos devs encontra na vida.

A arquitetura hexagonal, também chamada de Ports & Adapters, protege o núcleo do sistema. As regras de negócio ficam isoladas e se comunicam com o mundo externo apenas por portas bem definidas. Banco de dados, API, interface: detalhes que ficam do lado de fora.

A Clean Architecture evolui essa ideia organizando tudo em camadas nomeadas: entidades, casos de uso, interfaces, frameworks. Cada coisa no seu lugar, dependências sempre apontando para dentro. Faz sentido quando o projeto cresce e o time precisa falar a mesma língua.

A Onion Architecture segue a mesma filosofia, visualizada em camadas concêntricas com o domínio no centro. Se você entendeu Clean Architecture, vai se sentir em casa.

O DDD parte de uma premissa diferente: o código deve falar a língua do negócio. Entidades, agregados, repositórios, tudo modelado para refletir o mundo real. O esforço se justifica quando o domínio é complexo e cheio de regras que um modelo superficial não sustenta.

Microserviços dividem a aplicação em serviços pequenos, independentes, cada um rodando e escalando por conta própria. Faz sentido com times distribuídos, onde cada squad cuida do seu pedaço sem depender dos outros.

SOA conecta serviços maiores por um barramento central, o famoso ESB. Mais pesado que microserviços, mas ainda presente em ambientes corporativos com sistemas legados que precisam se integrar sem reescrita.

Event-Driven conecta componentes por eventos: um publica, outros escutam e reagem. Ninguém espera resposta de ninguém, o que torna o sistema assíncrono e preparado para alta performance.

Serverless elimina a gestão de servidor. Você escreve a função, a nuvem cuida do resto. Ideal para tarefas pontuais onde pagar só pelo que executa faz diferença no custo.

CQRS separa leitura e escrita em modelos distintos. Cada operação segue seu próprio fluxo, sem concorrência entre elas. Faz sentido quando a demanda de consulta é alta e performance de leitura é crítica.

Pipes & Filters processa dados em etapas sequenciais, onde cada filtro transforma e passa adiante. É o padrão natural para ETL e processamento em lote.

Muito bem, espero ter conseguido dar uma luz sobre esses tipos de arquiteturas. E se você saiu daqui sabendo que essas opções existem e quando cada uma faz sentido, já está à frente de muita gente.  

Até o próximo post!