A arquitetura de software é uma disciplina que começou a ser desenvolvida no final dos anos 1960 e vem crescendo em importância desde então – em ritmo cada vez mais acelerado, por sinal, seguindo o passo da transformação digital dos mais diversos mercados.

Em essência, ela ajuda a organizar as incontáveis possibilidades de desenvolvimento de softwares, por meio de padrões arquitetônicos. Com o apoio desses padrões, os desenvolvedores não precisam ficar constantemente “reinventando a roda” ao criar suas aplicações: podem se guiar por soluções já aplicadas com sucesso por outros.

De camadas e microsserviços a clientes e assinantes

Existem diversos padrões arquiteturais de software. Vamos falar dos mais comuns.

MVC (Model-View-Controller pattern): Como o nome sugere, esse padrão é dividido em três componentes principais – o modelo (que contém os dados da aplicação e a funcionalidade central); a visão (que exibe os dados da aplicação e interage com o usuário); e o controlador (que recebe o input do usuário e faz a mediação entre o modelo e a visão).

Uma das vantagens deste modelo é a facilidade com que múltiplos engenheiros podem trabalhar simultaneamente nos componentes sem entrar em conflito. Contudo, lidar com o framework em si pode ser uma tarefa complexa, já que ele envolve diversos níveis de abstração.

Linguagens de programação como JavaScript, Python, PHP e Java possuem frameworks de MVC para desenvolvimento de aplicações mobile e web.

Microsserviços (Microservices pattern): Este padrão envolve criar diversas aplicações (os ditos “microsserviços”) que podem funcionar de maneira interdependente. Dois pontos essenciais desse padrão são a ativação separada das unidades e a arquitetura distribuída. Ambos favorecem a escalabilidade e facilitam a atualização.

É um padrão altamente recomendado para APPs e websites com pequenos componentes. Para se trabalhar bem com microsserviços, porém, é importante saber lidar com a complexidade da arquitetura em si na hora de manter a interdependência dos componentes.

Cliente-servidor (Client-server pattern): Neste padrão, temos o solicitante (cliente) e o provedor (servidor) do que a aplicação oferece. Embora haja casos em que ambos estão no mesmo sistema, o mais usual é que eles se comuniquem através de uma rede, em hardwares separados.

O componente “cliente” interage com o servidor de maneiras específicas para que este execute os serviços solicitados. Um bom exemplo deste tipo de padrão é a própria Internet. Aplicações de compartilhamento de arquivos online e de e-mail também usam o modelo cliente-servidor.

O maior obstáculo nesse padrão é o elevado custo de construir e manter o servidor que geralmente centraliza e responde pelas diversas requisições.

Em camadas (layered pattern): O padrão em camadas é, possivelmente, o mais usado pelos desenvolvedores. É especialmente indicado para aplicações que envolvem diversos grupos de tarefas, cada qual com um diferente grau de abstração. Cada tarefa é representada por uma camada (uma unidade de módulos que provê um conjunto de serviços), e cada camada provê “serviços” para a próxima, em um padrão unidirecional.

Por exemplo, uma camada de apresentação lidaria com a interface do usuário e a lógica de comunicação do browser, enquanto uma camada de lógica de negócio executaria determinadas demandas do negócio.

Esse padrão é usado em muitos e-commerces e também em aplicações de desktop, e é ideal para aplicações com padrões estritos de testagem. É preciso, porém, levar dois desafios em conta: a complexidade e o custo de adicionar mais camadas – sendo que pode ser especialmente difícil separar as camadas.

O desafio da escolha

Naturalmente, existem muitos outros padrões arquiteturais de software, com suas vantagens e desafios, e mesmo os que abordamos no artigo merecem um estudo mais aprofundado.

Todos, porém, têm um objetivo em comum: definir as características básicas da aplicação, aprimorando a funcionalidade do produto em si e a eficiência do desenvolvimento.

É possível, também, utilizar mais de um padrão no desenvolvimento de um software. Escolher o(s) mais adequado(s) pressupõe um bom entendimento do negócio e, de modo mais específico, dos objetivos da aplicação.