Arquitetura de Software não é só um desenho de caixas e nem a escolha de um framework. É o conjunto de estruturas e decisões de alto impacto que define como o sistema é organizado e como ele consegue atender necessidades de negócio e atributos de qualidade ao longo do tempo.
ElementosQuais partes assumem responsabilidades?
RelaçõesComo elas se comunicam e dependem umas das outras?
RestriçõesO que limita ou orienta a solução?
DecisõesPor que a solução foi estruturada dessa forma?
Lente sistêmica: se cada função está correta isoladamente, mas o sistema falha sob carga, procure relações, dependências, gargalos, pontos únicos de falha e decisões estruturais. Arquitetura ajuda a raciocinar sobre o comportamento do sistema como um todo.
Por que isso importa?
Evolução
Adicionar mobile, trocar banco, integrar Pix ou mudar regras não deveria obrigar a reescrever todo o sistema.
Qualidade
Desempenho, segurança, disponibilidade, escalabilidade e manutenibilidade surgem do conjunto de decisões, não de uma função isolada.
Comunicação
Uma arquitetura registrada reduz ambiguidades entre produto, desenvolvimento, integração e operação.
Planejamento
Permite antecipar riscos, comparar alternativas e deixar explícito o preço de cada escolha.
Frase para prova: “Arquitetura descreve elementos, relações, restrições e decisões estruturais relevantes, conectando requisitos e atributos de qualidade às consequências da solução.”
As duas disciplinas se relacionam, mas não são sinônimas. Engenharia de Software cobre o ciclo de vida completo: levantamento, processo, implementação, testes, implantação, manutenção e gestão. Arquitetura foca as decisões estruturais que têm impacto amplo, caro de reverter e forte relação com qualidades e riscos.
ArquiteturaFronteiras, responsabilidades, dependências, tecnologias estruturais, implantação, atributos de qualidade, riscos, trade-offs e evolução.
EngenhariaProcessos, requisitos, projeto detalhado, construção, testes, qualidade, manutenção, gestão de configuração e entrega.
RelaçãoA arquitetura orienta decisões importantes da engenharia; a implementação e a operação produzem evidências que podem obrigar a revisar a arquitetura.
Erro comumSepará-las artificialmente. Arquitetura não é uma fase congelada no início: ela evolui durante o ciclo de vida.
ConcepçãoProblema, contexto, requisitos prioritários, restrições e riscos.
ElaboraçãoFronteiras, contratos, dados, tecnologias, protótipos e decisões.
ValidaçãoCenários, testes, medições e riscos remanescentes.
EvoluçãoEvidência nova → revisar hipóteses → ajustar decisões.
A função central do arquiteto não é “escolher a tecnologia mais nova”. É manter coerência entre contexto, requisitos, decisões, riscos e evolução, colaborando com negócio, desenvolvimento e operação.
1. Entender e priorizar
Objetivos, restrições, stakeholders, orçamento, prazo, volume, riscos e atributos de qualidade prioritários.
2. Comparar alternativas
Propor estruturas candidatas e analisar benefício, custo, risco e hipótese de cada uma.
3. Selecionar tecnologias
Com critérios explícitos: adequação, maturidade, conhecimento da equipe, custo, operação, integração e evolução.
4. Reduzir risco
Usar protótipos, spikes, testes de carga, concorrência, failover e experimentos antes de decisões caras virarem dependência.
5. Comunicar e registrar
Fronteiras, contratos, diagramas, ADRs, premissas e razões. A decisão precisa ser compreensível por quem vai manter o sistema.
6. Acompanhar evolução
Orientar implementação, observar produção e revisar decisões quando as condições mudarem.
Em prova: se a alternativa diz “escolher microserviços sempre”, “usar tecnologia mais recente” ou “delegar toda qualidade para testes”, desconfie. O arquiteto compara alternativas e valida consequências no contexto.
Nenhum estilo é “o melhor” em abstrato. A pergunta correta é: qual estrutura atende melhor estas forças, sob estas restrições, e qual complexidade ela introduz?
Monólito modular não é “arquitetura ruim”
Um monólito pode manter módulos e contratos claros, ser replicado horizontalmente e atender bem uma equipe pequena. Microserviços trazem implantação independente e escala seletiva, mas cobram observabilidade, rede, dados distribuídos, consistência, automação e maturidade operacional.
Regra de decisão: não migre para microserviços para “parecer moderno”. Migre quando houver uma pressão concreta que a separação em serviços resolva melhor do que a alternativa mais simples.
Interface / Apresentaçãorecebe ações do usuário e apresenta respostas.
Aplicação / Serviçoscoordena fluxos e casos de uso.
Domínio / Regrasrepresenta conceitos e regras estáveis do negócio.
Infraestruturabanco, APIs externas, mensageria, arquivos e frameworks.
MVC
ModelEstado, regras e comportamento do domínio; pode incluir persistência/abstrações de acesso conforme a implementação.
ViewApresentação da informação ao usuário.
ControllerInterpreta entrada e coordena a interação entre interface e modelo.
PegadinhaTrês camadas lógicas não exigem três servidores físicos. Estrutura lógica e implantação são decisões diferentes.
Clean Architecture
As regras mais importantes ficam no centro e detalhes tecnológicos na periferia. A Regra de Dependência diz que código das camadas internas não deve conhecer detalhes das camadas externas. Entidades e casos de uso não devem depender de banco, controller HTTP ou framework de UI.
Objetivo: proteger o núcleo contra mudanças frequentes de tecnologia. Banco, web framework e interface podem trocar sem reescrever regras centrais.
RF — o que o sistema fazComportamentos e serviços observáveis: cadastrar, consultar, reservar, aprovar, emitir, sincronizar.
RNF — como/quanto bemQualifica ou restringe RFs: tempo de resposta, disponibilidade, segurança, escala, portabilidade, manutenibilidade.
RestriçãoCondição que limita solução: legislação, plataforma obrigatória, orçamento, prazo, tecnologia já existente.
ASRRequisito que força ou influencia fortemente decisões arquiteturais por seu impacto, risco ou abrangência.
RNF fraco“O sistema deve ser rápido.”
RNF verificável“Com 5.000 usuários simultâneos, 95% das consultas respondem em menos de 500 ms.”
Por que importaAgora é possível escolher táticas e testar se a arquitetura atende o limite.
Formato de cenário de atributo de qualidade
FonteQuem/que origina o estímulo?
EstímuloQue evento ocorre?
AmbienteEm qual condição?
ArtefatoQual parte é afetada?
RespostaO que o sistema deve fazer?
MedidaQual limite objetivo prova sucesso?
Critério prático: se não dá para testar, medir ou observar, o RNF ainda está vago demais para orientar a arquitetura.
ExperiênciaUsabilidadeDesempenho
OperaçãoConfiabilidadeDisponibilidadeSuportabilidade
ProteçãoSegurança
EvoluçãoManutenibilidadeTestabilidadeFlexibilidadeReusabilidade
Ambiente / integraçãoEscalabilidadePortabilidadeInteroperabilidade
Disponibilidade
Estar acessível quando necessário. Poucos usuários não eliminam a necessidade de disponibilidade.
Escalabilidade
Capacidade de suportar crescimento de carga sem perda inaceitável de qualidade.
Desempenho
Tempo de resposta, throughput, utilização e comportamento sob carga definida.
Confiabilidade
Executar comportamento esperado de forma consistente ao longo do tempo.
Disponibilidade ≠ escalabilidade: um sistema pode ter pouca demanda e ainda exigir alta disponibilidade; pode escalar muito e continuar sujeito a falhas; e pode ser altamente disponível sem precisar crescer indefinidamente.
Uma tática é uma decisão de projeto voltada a influenciar uma resposta de qualidade. Nenhuma tática garante o resultado sozinha: ela cria uma hipótese que precisa ser verificada.
Mais requisições → replicar + balancearGanho: capacidade e tolerância à falha de instância.
Custo: estado externo, coordenação, banco/balanceador também precisam suportar carga.
Leituras frequentes → cacheGanho: menor latência e menos carga.
Custo: invalidação, consistência e dados potencialmente desatualizados.
Picos → fila + consumidoresGanho: absorve rajadas e desacopla processamento.
Custo: espera, duplicação, reprocessamento, backlog e observabilidade.
Falha de servidor → redundância + failoverGanho: continuidade do serviço.
Custo: infraestrutura, sincronização e testes de restauração/troca.
Dependência instável → timeout/retry/circuit breakerGanho: evita bloqueio e propagação de falha.
Custo: operação degradada, política de retry, idempotência e monitoramento.
Evolução frequente → módulos + contratosGanho: mudança localizada e fronteiras claras.
Custo: disciplina arquitetural e gestão de dependências.
Escala vertical × horizontal
VerticalMais CPU/memória na mesma máquina. É simples, mas tem limite físico e a instância continua sendo ponto de falha.
HorizontalMais instâncias do mesmo software atrás de um balanceador. Requer stateless ou estado compartilhado, health checks e dependências dimensionadas.
Pegadinha: replicar um monólito atrás de um balanceador é escala horizontal, mas o sistema continua sendo arquiteturalmente monolítico.
Uma arquitetura precisa de mais de uma representação porque públicos diferentes fazem perguntas diferentes. Uma única imagem com todos os detalhes costuma piorar produto, desenvolvimento e operação ao mesmo tempo.
StakeholderQuem precisa compreender ou influenciar algo?
ConcernQual preocupação/pergunta esse público possui?
ViewpointComo construir uma visão para responder a esse tipo de preocupação?
VisãoRecorte concreto da arquitetura para aquele sistema.
Negócio / Produto
Quem usa? Quais capacidades? O que integra? Prefere contexto, domínio e cenários.
Desenvolvimento
Onde implementar? Quais módulos e contratos? Prefere dependências, componentes e responsabilidades.
Operação
Onde executa? O que depende de quê? Onde falha? Prefere implantação, instâncias, comunicação e monitoramento.
Segurança / Serviço
Onde estão fronteiras, dados, riscos e controles? Pode precisar cruzar múltiplas visões.
Antes de desenhar: defina público + pergunta + escopo + legenda. Um nome de diagrama, sozinho, não determina uma visão.
O 4+1 organiza a arquitetura por preocupações diferentes. Não são níveis de zoom e não correspondem automaticamente a camadas de software.
LógicaResponsabilidades e domínio
Pergunta: quem representa e controla o quê? Possíveis representações: domínio, classes, objetos.
DesenvolvimentoOrganização do código
Pergunta: quais módulos podem depender de quais? Pacotes, componentes, módulos e organização para a equipe.
ProcessosExecução e concorrência
Pergunta: o que acontece em paralelo e como partes se comunicam em runtime? Sequência, processos, threads e mensageria.
FísicaSoftware na infraestrutura
Pergunta: onde as instâncias executam? Nós, máquinas, zonas, rede, implantação e topologia.
+1 CenáriosCostura e validação
Pergunta: como um fluxo atravessa as quatro visões? Cenários ajudam a verificar coerência e revelar lacunas.
Exemplo de falha: a reserva foi confirmada, mas o worker de e-mail falhou. Lógica: reserva continua confirmada; desenvolvimento: contrato isola notificação; processos: pendência é reprocessada; física: outra instância do worker pode retomar; +1: cenário conecta e testa tudo.
O C4 aproxima o olhar em níveis. A pergunta muda de “qual preocupação?” para “quanto detalhe estrutural precisamos mostrar?”.
1
ContextoSistema em foco, pessoas e sistemas externos. Responde quem usa e com quem integra. Banco, fila e APIs internas ainda não aparecem.
2
ContêineresAplicações executáveis e armazenamentos: web app, mobile, API, worker, banco, fila. Contêiner C4 não significa Docker.
3
ComponentesPartes internas de um contêiner central, com responsabilidades e relações. Ex.: controlador, serviço de reservas, gateway, repositório.
4
CódigoClasses, funções e estruturas internas de um componente. Normalmente opcional; detalhe só quando agrega valor.
Representações complementares
DinâmicoExplica a ordem de uma interação específica. Ex.: Portal → API → Banco → Fila → Worker → provedor de e-mail.
ImplantaçãoMostra instâncias e domínios de falha. Duas APIs podem ser duas instâncias do mesmo contêiner lógico.
Portal web
→
API
→
Banco
→
Fila
→
Worker
→
E-mail
Na Atividade A2: escolha um caminho principal. No 4+1, faça as quatro visões e use os cenários +1 para conectá-las. No C4, use Contexto, Contêineres, Componentes de um contêiner central e dinâmica do fluxo principal; explique também uma exceção/falha.
NecessidadeRF + RNF mensurável + restrições.
DecisãoAlternativa escolhida + alternativa descartada + custo.
EvidênciaCenário + teste + métrica que prova ou refuta a hipótese.
ComunicaçãoVisão e representação adequadas ao público.
Modelo de justificativa para discursiva
“Escolhi X para atender Y; aceito Z e verifico com W.”
Exemplo: “Escolho duas instâncias stateless atrás de balanceador para atender o RNF de pico e reduzir ponto único de falha; aceito maior complexidade operacional e verifico com teste de carga + desligamento controlado de uma instância.”
ADR simplificado
ContextoQual problema, pressão ou restrição exige uma decisão?
AlternativasQuais opções foram consideradas e em que condições funcionam?
DecisãoQual foi escolhida e por qual critério?
ConsequênciasBenefícios, custos, riscos, dívidas e impactos futuros.
EvidênciaComo medir e revisar a decisão?
