O que é arquitetura de software?

A arquitetura de software é o quadro geral de alto nível de um sistema, desenhado antes mesmo de qualquer linha de código ser escrita. Ela define a estrutura e a organização do software. Nesse estágio, o foco não está em detalhes de implementação, não se fala em design patterns, mas em como o sistema será estruturado para atender às metas do projeto.

Muitos autores tomam diferentes caminhos para explicar isso, mas, de maneira geral, podemos dizer que cabe à arquitetura de software aquilo que é de alto nível, que define os pilares técnicos do sistema antes da sua implementação concreta. Cabe ao arquiteto aferir quais estilos arquiteturais serão adotados, se será monolítico ou de microserviços, o que por sua vez irá influenciar a decisão a respeito do padrão arquitetural, como hexagonal ou onion, além dos requisitos não funcionais e críticos para o projeto, como baixa latência, segurança, escalabilidade, tolerância a falhas etc.

Essas decisões de alto nível definem o rumo que todo o desenvolvimento seguirá, influenciando diretamente as camadas de baixo nível, mais próximas da implementação do software. Por exemplo, se a escolha for por uma arquitetura de microserviços, considerando uma série de requisitos anteriores, a etapa de implementação da tecnologia, como do framework, será diretamente impactada.

Por se tratar de uma abordagem de alto nível, é natural que o sucesso do projeto dependa também das decisões arquiteturais, que devem guiar as escolhas subsequentes, e não o contrário, como se, por exemplo, a escolha de um framework tivesse prioridade sobre a definição da arquitetura.

O que podemos dizer, buscando generalizar a atuação do arquiteto, é que ele leva em conta os requisitos funcionais, que definem o que o sistema deve fazer, como cadastros, autenticação e processamento de pedidos, e os requisitos não funcionais, que determinam como o sistema deve se comportar. Assim, a arquitetura de software atua tanto com a visão de tecnologia, como com a de um estrategista.

Uma última coisa que devo dizer é que comum a diferenciação de design de software e arquitetura de software. Enquanto a segunda, como eu disse, abraça fatores de alto nível, o design de software irá abordar aspectos de nível mais baixo, como a implementação de classes, funções e módulos individuais dentro da estrutura definida pela arquitetura.

Arquitetura Monolítica

Em aplicações monolíticas, a interface do usuário, o servidor e o banco de dados geralmente estão integrados em uma única base de código. Por exemplo, um projeto desenvolvido com o framework Laravel com um único repositório em que front-end e backend estão integrados juntos é um monólito.

As aplicações com essa arquitetura são mais fáceis de iniciar, pois exigem pouco planejamento inicial e permitem adicionar módulos gradualmente. Isso torna o desenvolvimento inicial mais rápido e simples, ideal para projetos pequenos ou médios.

No entanto, à medida que o sistema cresce, podem surgir problemas como forte acoplamento entre módulos, builds mais demoradas, maior risco de que falhas em uma parte afetem todo o sistema e dificuldade para escalar apenas funcionalidades específicas.

É importante destacar que esses desafios não são críticos para todos os projetos. Eles se tornam relevantes principalmente em sistemas complexos, de grande porte, que exigem alta disponibilidade, escalabilidade e baixo acoplamento entre módulos. Diria, sem sombra de dúvidas, que serve a maioria das aplicações.

Além disso, como veremos adiante, as alternativas a uma arquitetura monolítica também apresentam desafios ainda que resolvam muitos dos problemas dessa arquitetura.

Arquitetura de Microserviços

Microserviços são uma abordagem arquitetural em que uma aplicação é dividida em pequenos serviços independentes, cada um responsável por uma funcionalidade específica do sistema.

Diferente de um monólito, cada microserviço possui seu próprio código, banco de dados ou esquema e lógica de negócio, podendo ser desenvolvido, implantado e escalado de forma independente. A comunicação entre os serviços ocorre geralmente por APIs, como HTTP/REST ou sistemas de mensagens assíncronas.

Entre as vantagens dos microserviços estão: maior resiliência, pois falhas em um serviço não derrubam todo o sistema, apenas aqueles que, talvez, tenham maior dependência dele; escalabilidade, visto que é possível isolar recursos e aumentar a capacidade apenas das partes do sistema que necessitam, sendo ideal, inclusive, que cada serviço tenha até mesmo seu próprio banco de dados; flexibilidade tecnológica, permitindo que cada serviço utilize a tecnologia mais adequada para o seu caso.

Por outro lado, essa arquitetura traz desafios também. A complexidade de integração aumenta muito, é necessário gerenciar a automação de deploys independentes, lidar com latência em chamadas entre serviços, manter a consistência de dados entre outras coisas.

Enfim, microserviços são recomendados principalmente para sistemas complexos, que exigem alta disponibilidade, escalabilidade e desenvolvimento paralelo por múltiplas equipes, ou seja, de maneira geral, em que essa abordagem distribuída, apesar dos desafios, é uma necessidade arquitetural.