Arquitetura de software: o que é, tipos, modelos e como funciona

1. O que é arquitetura de software?

Arquitetura de software é o conjunto de estruturas e decisões que define como um software se organiza, como suas partes se comunicam e como atende às necessidades do negócio e aos requisitos de qualidade. Ela orienta tanto a construção quanto a evolução do sistema. 

Fala aí, Padawan! Pense em uma plataforma de cursos: cadastrar alunos, processar pagamentos e liberar aulas são funcionalidades. Decidir onde essas responsabilidades ficam, como trocam informações e o que acontece quando o pagamento falha é trabalho de arquitetura. Para estudar o assunto, inclusive para concursos, precisamos entender as consequências dessas escolhas.

A arquitetura de um sistema pode abranger software, infraestrutura, equipamentos e integrações. Dentro desse conjunto, a arquitetura de software concentra-se na organização dos elementos de software e em seu comportamento. A escolha de uma linguagem ou de um banco de dados participa dessa discussão, mas precisa responder a uma necessidade concreta.

2. Componentes e decisões envolvidas

Os componentes representam partes com responsabilidades definidas: interface do usuário, processamento de pedidos, controle de acesso, armazenamento e integração com serviços externos, por exemplo. Sua dimensão depende do nível de análise: podemos observar aplicações inteiras, módulos internos ou serviços separados.

As conexões entre esses componentes também fazem parte da arquitetura. Uma API, ou interface de programação, estabelece como um componente pode usar outro. Uma chamada síncrona espera uma resposta; uma comunicação assíncrona permite continuar o trabalho enquanto uma mensagem aguarda processamento. Cada alternativa muda o tempo de resposta, o tratamento de falhas e a coordenação das operações.

Entre os fundamentos da arquitetura de software estão coesão, acoplamento e separação de responsabilidades. Coesão significa reunir elementos que cumprem um propósito relacionado. Acoplamento representa o grau de dependência entre partes. Separar responsabilidades ajuda a evitar que uma alteração na apresentação, por exemplo, exija modificar as regras de pagamento.

As decisões precisam considerar dois grupos de requisitos. Os funcionais descrevem o que o sistema faz, como registrar uma matrícula. Os atributos de qualidade descrevem condições de funcionamento, como segurança, disponibilidade, desempenho e facilidade de manutenção. Uma arquitetura permite analisar essas qualidades antes que problemas apareçam em produção. 

Entre as principais perguntas arquiteturais estão:

• Divisão de responsabilidades: quais módulos existirão e quais regras pertencem a cada um?
• Dados: quem pode alterar cada informação e quais operações precisam ser confirmadas em conjunto?
• Comunicação: quais interações exigem resposta imediata e quais podem aguardar?
• Falhas: como o sistema reage quando uma dependência fica indisponível?
• Segurança: como identifica usuários, verifica permissões e protege informações?
• Implantação: quais partes são publicadas juntas e quais podem receber atualizações separadas?
• Operação: como a equipe identifica erros, acompanha desempenho e recupera o serviço?

E o que faz um arquiteto de software? Ele transforma necessidades e restrições em decisões técnicas justificadas. Conversa com as pessoas envolvidas, compara alternativas, avalia riscos e acompanha a implementação. Esse trabalho pode ser exercido por um profissional dedicado ou compartilhado pela equipe; exige conhecer o negócio e verificar se as decisões funcionam na prática.

3. Principais estilos arquiteturais e modelos

Os tipos de arquitetura de software organizam dimensões diferentes de um sistema. Monólitos e microsserviços dizem respeito, entre outros aspectos, à distribuição e à implantação. Camadas e arquitetura hexagonal orientam a organização interna. Eventos orientam interações. Por isso, essas abordagens podem ser combinadas.

Arquitetura monolítica e monólito modular. Em um monólito, as principais funcionalidades são publicadas como uma unidade. No monólito modular, essa unidade possui divisões internas explícitas, como alunos, cursos e matrículas. É possível manter uma aplicação bem organizada e também executar várias cópias dela para atender mais usuários. A dificuldade aparece quando partes diferentes precisam evoluir ou receber recursos de maneira independente.

Arquitetura em camadas. Separa responsabilidades, geralmente em apresentação, negócio e acesso a dados. É útil para organizar aplicações administrativas e transacionais. Atenção à distinção: camadas são divisões lógicas; níveis físicos de implantação, frequentemente chamados de tiers, podem executar em processos ou máquinas diferentes. Três camadas de código não exigem três servidores. 

Arquitetura de microsserviços. Distribui capacidades de negócio entre serviços com autonomia de implantação e responsabilidade sobre seus dados. Em uma plataforma de ensino, cobrança e catálogo podem evoluir separadamente. Essa autonomia exige lidar com comunicação pela rede, falhas parciais, compatibilidade entre interfaces e consistência dos dados. A separação, por si só, não garante isolamento de falhas. 

Arquitetura orientada a eventos. Componentes publicam acontecimentos, como “Pagamento confirmado”, e outros reagem a eles. A liberação do curso e o envio de uma notificação podem ocorrer a partir desse evento. Quando a comunicação é assíncrona, os efeitos podem aparecer em momentos diferentes. É necessário planejar mensagens repetidas, atrasos e eventuais problemas de ordenação. 

Arquitetura orientada a serviços — SOA. Organiza capacidades acessíveis por contratos de serviço, frequentemente com foco na integração de sistemas de uma organização. Pode conectar cadastro, faturamento e atendimento. SOA e microsserviços compartilham ideias de orientação a serviços, mas diferem em práticas e prioridades. SOA não exige um barramento central, e microsserviços não se definem apenas pelo tamanho do código.

Arquitetura hexagonal e arquitetura limpa. Ambas procuram proteger as regras de negócio das tecnologias externas. Na hexagonal, portas definem interfaces de interação e adaptadores conectam banco de dados, interface gráfica ou serviços externos. A arquitetura limpa também enfatiza que as dependências do código apontem para as políticas internas. São abordagens relacionadas, com formulações próprias, aplicáveis dentro de monólitos ou serviços. 

Pipes and filters — dutos e filtros. Organiza o processamento em etapas conectadas. Um arquivo pode passar por leitura, validação, transformação e armazenamento. Cada filtro executa uma transformação, e os dutos transportam os resultados. A abordagem é adequada a fluxos de processamento, mas exige cuidado quando as etapas dependem de estado compartilhado ou precisam coordenar mudanças complexas.

Também é importante distinguir organização de representação. MVC, ou Modelo–Visão–Controlador, separa responsabilidades relacionadas aos dados e regras, à apresentação e ao tratamento das entradas. Já o C4 ajuda a representar a arquitetura em diferentes níveis: contexto, contêineres, componentes e código. Nesse modelo, “contêiner” pode ser uma aplicação ou um banco de dados; não significa necessariamente um contêiner Docker. 

4. Comparação de vantagens, limitações e trade-offs

Um trade-off é uma escolha que favorece determinados objetivos e impõe custos a outros. A tabela sintetiza os compromissos das abordagens apresentadas; elas não são alternativas necessariamente exclusivas.

Distribuir uma operação entre serviços, por exemplo, pode permitir atualizações independentes, mas acrescenta chamadas de rede e possibilidades de falha. Se a conclusão depender de vários serviços disponíveis ao mesmo tempo, a disponibilidade do fluxo pode piorar. A arquitetura precisa incluir mecanismos de recuperação, além da divisão em serviços. 

5. Como escolher uma arquitetura conforme o projeto

A escolha deve partir do problema, das restrições e das qualidades prioritárias. “O sistema precisa ser rápido” é uma orientação vaga. “95% das consultas devem terminar em até dois segundos, sob uma carga definida” oferece um critério verificável. Orçamento, prazo e experiência da equipe também influenciam a decisão. 

Para um produto novo, com uma equipe pequena e regras ainda em descoberta, um monólito modular costuma ser um ponto de partida razoável. Ele permite aprender sobre o negócio antes de estabilizar fronteiras entre serviços. Essa recomendação depende do contexto: requisitos conhecidos de isolamento ou autonomia podem justificar outra escolha desde o início. 

Se existem várias equipes, fronteiras de negócio compreendidas e necessidade real de publicar ou dimensionar partes separadamente, vale avaliar microsserviços. Se a necessidade principal é executar tarefas sem bloquear o usuário, uma fila e um processo de trabalho podem bastar. Para regras de negócio complexas, a organização hexagonal pode ajudar, independentemente da quantidade de serviços.

Um processo de decisão útil é:

1. Identificar as operações essenciais e as consequências de suas falhas.
2. Definir metas mensuráveis de desempenho, disponibilidade e recuperação.
3. Mapear restrições de equipe, prazo, orçamento e sistemas existentes.
4. Comparar poucas alternativas com base nessas prioridades.
5. Testar a hipótese mais arriscada com um protótipo ou experimento.
6. Registrar a decisão, as alternativas rejeitadas e suas consequências.
7. Revisar a escolha quando houver evidências de que o contexto mudou.

Esse registro pode assumir a forma de um ADR, ou registro de decisão arquitetural. Um documento curto explicando contexto, escolha e consequências ajuda a equipe a compreender por que determinada solução existe.

6. Exemplo prático: arquitetura de uma plataforma de cursos

Imagine uma plataforma construída por quatro desenvolvedores. Ela precisa cadastrar alunos, vender cursos e liberar conteúdo após a confirmação do pagamento. Nesse cenário hipotético, adotaremos um monólito modular com os módulos Alunos, Catálogo, Matrículas e Pagamentos, além de uma tarefa de envio de notificações em segundo plano.

O fluxo funciona assim:

1. O aluno solicita a compra de um curso, e o sistema registra uma matrícula pendente.
2. O módulo Pagamentos solicita a cobrança ao provedor externo.
3. O provedor envia uma confirmação. O sistema verifica sua autenticidade e os dados da operação.
4. Uma transação local registra o pagamento confirmado, ativa a matrícula e grava uma notificação pendente. Se essa transação falhar, nenhuma dessas alterações é confirmada.
5. Uma tarefa em segundo plano envia a notificação e registra o resultado, realizando novas tentativas quando necessário.

A confirmação do provedor pode chegar repetida. Por isso, o processamento deve ser idempotente: repetir a mesma confirmação não pode gerar uma nova matrícula nem aplicar novamente seus efeitos. Uma identificação única da operação ajuda a controlar esse comportamento.

A decisão de enviar a notificação em segundo plano tem uma consequência clara: o acesso ao curso pode ser liberado antes da chegada do e-mail. Isso é aceitável no cenário proposto e evita que uma falha no envio impeça a matrícula. A equipe deve acompanhar notificações pendentes e disponibilizar meios de recuperação.

Se, no futuro, a geração de certificados exigir muito processamento, a equipe poderá avaliar sua execução separada. Essa evolução deve responder a medições e necessidades concretas. Padawan, vamos praticar um pouco o que vimos e aprofundar em alguns conceitos com questões?

FGV – 2026 – MPE-ES – Agente Técnico – Desenvolvedor

Durante a revisão de uma arquitetura, um arquiteto de software analisa duas abordagens para estruturação de uma aplicação corporativa:

• Proposta A: todo o processamento de regras de negócio e acesso a dados ocorre no lado do servidor, e o cliente recebe apenas páginas renderizadas.
• Proposta B: parte significativa da lógica de negócio é executada diretamente no navegador do usuário, com o servidor funcionando basicamente como uma camada de persistência e serviços.

Sobre a classificação dessas propostas quanto à arquitetura de três camadas, assinale a afirmativa correta.

Alternativas

A) A Proposta A é incompatível com a arquitetura de três camadas, pois exige que toda a lógica resida no cliente.

B) A Proposta B é compatível com a arquitetura de três camadas, pois distribui corretamente a lógica entre apresentação e negócio.

C) A Proposta A é compatível com a arquitetura de três camadas, e a Proposta B aproxima-se de uma arquitetura em que a separação entre camadas de apresentação e lógica de negócio é comprometida.

D) A Proposta A viola a arquitetura de três camadas, pois mantém a lógica de negócio no servidor web em vez do servidor de aplicações.

E) A Proposta B atende aos princípios da arquitetura de três camadas, uma vez que o servidor de persistência e serviços constitui a camada de dados.

Gabarito: C, 

A) Incorreta. A arquitetura de três camadas separa as responsabilidades de apresentação, negócio e dados. Ela não exige que a lógica de negócio resida no cliente. A Proposta A é compatível com essa organização: o servidor pode executar as regras de negócio e acessar os dados em camadas distintas, entregando ao navegador as páginas renderizadas.

B) Incorreta. A execução de parte significativa das regras de negócio no navegador não demonstra, por si só, uma separação adequada entre apresentação e negócio. Na interpretação da questão, a Proposta B concentra essas responsabilidades no cliente e reduz o papel do servidor, afastando-se da distribuição tradicional de três camadas. Entretanto, executar código de negócio no navegador não significa necessariamente misturá-lo ao código de apresentação: isso depende da organização interna da aplicação.

C) Correta. A Proposta A permite manter a apresentação, o processamento das regras de negócio e o acesso aos dados separados, mesmo com o processamento concentrado no servidor. Já a Proposta B, conforme a leitura pretendida pelo enunciado, aproxima-se de um modelo de cliente rico, com maior responsabilidade de processamento no navegador e possível comprometimento da separação entre apresentação e negócio. A expressão “aproxima-se” é relevante: indica uma tendência, sem afirmar que toda aplicação com lógica no navegador possui essa deficiência.

D) Incorreta. O enunciado informa apenas que o processamento ocorre no lado do servidor. Ele não afirma que as regras de negócio estão implementadas no servidor web, nem exclui a existência de um servidor de aplicações. Além disso, camadas lógicas podem compartilhar um mesmo ambiente de execução: a separação de responsabilidades não exige, necessariamente, servidores físicos distintos.

E) Incorreta. A existência de persistência e serviços no servidor não garante uma arquitetura de três camadas. É necessário identificar a separação entre apresentação, negócio e dados. Além disso, serviços não pertencem automaticamente à camada de dados: eles podem executar regras de negócio, coordenar operações ou integrar sistemas.

Atenção, Padawan: a questão contém uma simplificação. Camada lógica não é sinônimo de local de execução. Uma aplicação pode separar apresentação e negócio em módulos distintos dentro do navegador. Assim, C é a melhor alternativa no contexto da questão, mas a localização do código, isoladamente, não permite concluir que a separação lógica foi comprometida.

FGV – 2026 – NAV Brasil – Engenheiro – Software

No desenvolvimento de um novo painel web para visualização de boletins meteorológicos, a equipe técnica optou por uma arquitetura em camadas padrão de mercado. A meta é garantir a separação de conceitos e facilitar manutenções futuras no código do sistema de navegação aérea.

A arquitetura em camadas organiza o sistema de forma que cada camada forneça serviços para a camada imediatamente superior e utilize os serviços da camada imediatamente inferior.

Assinale a afirmativa correta sobre as regras de acoplamento e dependência nesse padrão arquitetural clássico.

A) A camada de apresentação deve se comunicar diretamente com o driver de banco de dados, ignorando a lógica de negócio.

B) As alterações realizadas na camada de persistência de dados devem obrigatoriamente forçar a reescrita de toda a interface gráfica.

C) A camada de lógica de negócio deve idealmente ser independente dos detalhes de implementação da interface de usuário instalada.

D) Cada camada criada no sistema possui permissão irrestrita para acessar qualquer outra camada, sem respeitar a hierarquia.

E) O isolamento entre as camadas impede que o sistema funcione em servidores distintos, exigindo uma implantação monolítica.

Gabarito: C.

A) Incorreta. No modelo descrito, a apresentação deve solicitar operações à camada de negócio, que utiliza os serviços da camada de persistência. Acessar diretamente o driver — componente que permite a comunicação com o banco — pularia camadas e violaria a hierarquia estabelecida. Isso também vincularia a interface aos detalhes de acesso aos dados.

B) Incorreta. A separação em camadas busca reduzir a propagação das mudanças. Uma alteração interna na persistência, como a otimização de uma consulta, pode ocorrer sem modificar a interface gráfica, desde que preserve o contrato e o comportamento esperado pelas demais camadas. Algumas mudanças podem afetar várias camadas, mas a reescrita de toda a interface não é uma consequência obrigatória.

C) Correta. A lógica de negócio deve concentrar as regras da aplicação, independentemente de como as informações são apresentadas. Por exemplo, uma regra que determina se um boletim meteorológico está dentro do prazo de validade não deve depender de botões, cores ou componentes gráficos. Essa independência facilita testes, manutenção e reutilização das regras em diferentes interfaces.

D) Incorreta. O acesso irrestrito contraria a organização hierárquica descrita. Na arquitetura em camadas estrita, cada camada utiliza os serviços da camada imediatamente inferior. Respeitar essas fronteiras evita dependências desordenadas e reduz o acoplamento, isto é, o grau de dependência entre as partes do sistema.

E) Incorreta. A separação em camadas é uma organização lógica de responsabilidades, não uma imposição sobre a implantação física. As camadas podem executar no mesmo ambiente ou ser distribuídas entre servidores, com mecanismos de comunicação apropriados. Portanto, esse padrão não exige uma implantação monolítica.

CESPE / CEBRASPE – 2026 – UNEAL – Analista Administrativo – Área: Análise de Sistemas

Com o objetivo de modernizar seus sistemas de atendimento ao cidadão, determinado órgão público está reestruturando a infraestrutura e o design de sua plataforma web principal. O projeto prevê a adoção de padrões arquiteturais no front-end para melhorar a responsividade, além de uma topologia de back-end que separa rigorosamente o recebimento de requisições e a entrega de conteúdo estático do processamento intensivo de regras de negócio transacionais.

Considerando essa situação hipotética, julgue o item seguinte:

“Ao adotar a arquitetura single page application (SPA) no front-end do portal, a responsividade será alcançada por meio do recarregamento completo da página no navegador a cada interação do cidadão com o sistema.”

Gabarito: Falso.

A afirmação inverte o funcionamento típico de uma SPA — aplicação de página única. Nesse modelo, após o carregamento inicial, as interações e a navegação interna normalmente ocorrem por meio da atualização dinâmica do conteúdo, sem recarregar a página inteira.

O código executado no navegador controla essas atualizações e, quando necessário, solicita dados ao servidor por meio de APIs. Ao receber a resposta, modifica as partes relevantes da interface.

Por exemplo, ao consultar o andamento de um requerimento, o cidadão pode visualizar o resultado na área central do portal, enquanto o menu e o cabeçalho permanecem carregados. Isso pode proporcionar uma interação mais fluida.

O recarregamento completo a cada navegação é mais característico de aplicações tradicionais com múltiplas páginas. Mesmo nessas aplicações, porém, algumas interações podem atualizar apenas parte da tela.

Adotar SPA não garante automaticamente maior velocidade ou responsividade. O resultado depende da implementação, do volume de código carregado e do tempo de resposta dos serviços. Além disso, a adaptação visual a diferentes tamanhos de tela depende do design responsivo, e não da adoção de SPA.

FGV – 2026 – TJ-SC – Analista de Sistemas

Em uma aplicação corporativa de um tribunal, os usuários acessam o sistema por meio de navegadores instalados em suas estações de trabalho. As regras de negócio, o controle de acesso e a comunicação com o banco de dados são centralizados em servidores da instituição. As estações dos usuários apenas enviam requisições, recebem respostas e exibem as telas da aplicação, sem executar localmente as principais rotinas de processamento.

A arquitetura da aplicação descrita é caracterizada como:

Alternativas

A) Arquitetura ponto a ponto.

B) Arquitetura monolítica embarcada.

C) Arquitetura orientada a eventos.

D) Arquitetura serverless.

E) Arquitetura cliente-servidor.

Gabarito: E.

A) Incorreta. Na arquitetura ponto a ponto, ou peer-to-peer (P2P), os participantes podem atuar tanto como consumidores quanto como fornecedores de recursos e serviços. O enunciado apresenta uma divisão clara: as estações solicitam serviços, enquanto os servidores concentram o processamento e o acesso aos dados.

B) Incorreta. Uma aplicação monolítica reúne suas principais funcionalidades em uma unidade de implantação. Já um sistema embarcado é integrado a um equipamento para desempenhar funções específicas. O enunciado não descreve um sistema embarcado nem informa como o software dos servidores está organizado internamente. Uma aplicação monolítica pode, inclusive, participar de uma arquitetura cliente-servidor.

C) Incorreta. A arquitetura orientada a eventos organiza a comunicação em torno da produção e do consumo de acontecimentos, como “Processo distribuído” ou “Documento protocolado”. O enunciado destaca o envio de requisições pelos clientes e o processamento centralizado nos servidores, sem apresentar elementos que caracterizem a orientação a eventos.

D) Incorreta. Em uma arquitetura serverless, a infraestrutura de execução é gerenciada por uma plataforma, reduzindo a necessidade de a equipe administrar diretamente os servidores. Isso não significa ausência de servidores. O cenário não apresenta esse modelo de execução; descreve a distribuição de responsabilidades entre estações clientes e servidores institucionais.

E) Correta. A arquitetura cliente-servidor separa quem solicita os serviços de quem os fornece. No cenário:

• Clientes: os navegadores enviam requisições, recebem respostas e apresentam as telas.
• Servidores: executam as regras de negócio, verificam permissões e coordenam o acesso ao banco de dados.

Como as estações executam pouca lógica local e dependem dos servidores para o processamento principal, o cenário também caracteriza o uso de clientes leves, ou thin clients.

CESPE / CEBRASPE – 2026 – FUNPRESP-JUD – Analista de Tecnologia da Informação – Especialidade: Desenvolvimento de Sistemas

A respeito da arquitetura cliente-servidor aplicada aos sistemas gerenciadores de bancos de dados (SGBD) em três camadas, bem como da arquitetura, das ferramentas e dos padrões de persistência de dados do ecossistema Microsoft .NET, julgue o item.

“Na arquitetura cliente-servidor em duas camadas, o processo cliente estabelece uma conexão direta com o SGBD por meio de drivers específicos de conectividade, configuração que, sob a perspectiva da infraestrutura, exige que cada estação de trabalho seja responsável pelo processamento da camada de aplicação e disponha de mecanismos de autenticação para acesso direto ao servidor de banco de dados, fazendo com que o número de conexões simultâneas seja aproximadamente proporcional ao número de usuários ativos no sistema.”

Gabarito: Verdadeiro,

Na arquitetura cliente-servidor em duas camadas, a aplicação instalada na estação do usuário comunica-se diretamente com o SGBD, sem um servidor de aplicações intermediando esse acesso:

Aplicação cliente → SGBD

Nesse modelo tradicional, o cliente concentra a interface e parte relevante da lógica da aplicação, enquanto o servidor de banco de dados executa consultas, gerencia transações e armazena as informações. A conexão utiliza um driver ou provedor de acesso a dados compatível com o SGBD.

Como o acesso é direto, cada instalação cliente precisa dos componentes de conectividade, das configurações de conexão e de um mecanismo de autenticação aceito pelo banco. Isso não exige armazenar usuário e senha na estação: a autenticação pode, por exemplo, utilizar a identidade integrada do usuário.

A afirmação sobre o número de conexões expressa uma tendência típica: conforme aumenta o número de usuários com aplicações conectadas, cresce a quantidade de conexões mantidas com o banco. Se cada cliente mantiver uma conexão, cem clientes conectados representarão aproximadamente cem conexões.

Essa relação, entretanto, não é uma igualdade obrigatória. Uma aplicação pode abrir várias conexões, mantê-las apenas durante determinadas operações ou reutilizá-las por meio de um pool. Em aplicações instaladas separadamente nas estações, esses pools normalmente são locais a cada processo, sem concentrar as conexões de todos os usuários em um único intermediário.