Arquitetura de software: o que é e como escolher?

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.

Testes End-to-End no mundo SAP

Como testar processos complexos e integrados aos sistemas SAP

Ambiente SAP são complexos e interligados à várias outras plataformas, formando uma teia de dados difícil de gerenciar, garantindo segurança e estabilidade das aplicações.

Neste White Paper apresentamos alguns destes desafios e também algumas abordagens que podem lhe ajudar a solucionar estes dilemas.

Baixe agora mesmo