Quais partes importantes existem?
AULA TÉCNICA · 65 MIN · FUNDAMENTOS DE ARQUITETURA
Como pensar
a arquitetura de software
Aprenda a reconhecer as partes de um sistema, escolher como elas se comunicam e justificar cada escolha pelos requisitos e custos envolvidos.
Começar Ao final, você vai conseguir explicar a estrutura e os custos de cada escolha.
01 · CONCEITO02 · ESCALA NA AWS03 · EVENTOS
VISÃO DE CONTEXTOFIG. 01
ARQUITETURA DE SOFTWAREREQUISITOS → ESTRUTURA ↓
01 FUNDAMENTOS · 6 MIN
Arquitetura é a
estrutura do sistema.
Ela organiza as partes importantes, suas relações e as decisões que atendem a quem usa e opera o sistema, considerando prazo, equipe, custo e segurança. Um diagrama mostra uma visão dessa estrutura; não é a arquitetura inteira.
Como as partes se comunicam?
Quem é responsável por cada regra e dado?
O que o sistema precisa garantir?
EXEMPLO
Em uma aplicação de projetos, o navegador chama a API, a API verifica o acesso e consulta os dados. Essas partes, suas responsabilidades e suas relações formam uma visão da arquitetura.
02 COMUNICAÇÃO · 5 MIN
Cliente-servidor:
quem faz o quê?
O cliente apresenta a interface. O servidor recebe as requisições, aplica as regras e acessa os dados. Assim, web e app podem usar a mesma API.
Cliente
Envia filtros e parâmetros.
INTERFACEAPI
Valida método, rota e formato.
CONTRATODomínio
Aplica regras e permissões.
SERVIDORPersistência
Consulta ou grava os dados.
ARMAZENAMENTOFLUXO
O cliente envia. A API valida. O banco persiste.
✳IDEIA-CHAVE
Cliente-servidor explica a comunicação entre partes. Camadas e módulos explicam como o código do servidor é organizado.
03 EVOLUÇÃO · 5 MIN
A aplicação ficou lenta.
O que medir primeiro?
Escalar é uma decisão baseada em evidências. Meça o caminho da requisição para descobrir qual parte limita o sistema.
Meça a operação
Registre tempo de resposta, erros e uso de CPU, memória e banco.
Encontre o limite
Descubra qual componente está consumindo o tempo ou esgotando recursos.
Trate o gargalo
Altere essa parte e meça de novo. Mais servidores de API não resolvem consultas lentas no banco.
SE O LIMITE FOR A CPU DA APIADICIONE INSTÂNCIAS DO MESMO SERVIÇO
CLIENTES→API ÚNICA→BANCO
CLIENTES→BALANCEADOR→API 1API 2API 3→BANCO
Isso distribui a carga da API. Primeiro confirme que a API é o gargalo e que o banco suporta a carga adicional.
04 ESTRUTURA ESCALÁVEL NA AWS · 10 MIN
Do pedido aos dados:
qual serviço faz o quê?
Siga uma requisição pelas camadas. Depois compare duas formas de receber tráfego e veja qual recurso ampliar quando cada parte vira um gargalo.
CAMINHO A · APLICAÇÃO EM MÁQUINAS VIRTUAISDUAS ZONAS DE DISPONIBILIDADE
REDE PRIVADA · GRUPO DE DESTINOS · COMPUTAÇÃO
ZONA AEC2 · aplicaçãomáquina virtual ZONA BEC2 · aplicaçãomáquina virtual
O Auto Scaling ajusta quantas máquinas rodam. As zonas são partes isoladas de uma região da AWS; distribuir instâncias entre elas reduz o impacto de uma falha local.
↓DADOS · ACESSO PRIVADOAmazon RDSBanco gerenciado. Multi-AZ mantém uma cópia de espera para assumir em falha; réplica de leitura distribui consultas, mas pode ter atraso.
ESCOLHA A ENTRADA PARA O SEU TIPO DE APLICAÇÃOCAMINHO A OU CAMINHO B
Gerencia uma API
Define rotas, autorização e limites de chamadas; pode encaminhar para Lambda ou para uma API existente.
Útil quando esses recursos de gestão fazem parte do requisito.Distribui requisições web
Encaminha HTTP para aplicações saudáveis em EC2 ou ECS (contêineres), com regras por caminho ou domínio.
Útil na frente de uma aplicação que a equipe opera.ALB e API Gateway resolvem problemas relacionados, mas têm funções diferentes. São opções de entrada; não precisam ser usados juntos. API Gateway também pode chamar uma aplicação HTTP.
EXEMPLO DO CAMINHO B
Cliente→API Gateway→Lambda ou API→Dados
Auto Scaling
Ajusta quantas instâncias rodam conforme métricas e limites. O balanceador distribui as chamadas entre elas.
Cache ou réplica
Cache evita consultas repetidas; réplica atende leituras. Réplicas podem apresentar dados atrasados.
SQS + worker
A fila guarda o trabalho para processamento posterior. O worker pode receber a mesma mensagem mais de uma vez.
EventBridge
Encaminha eventos a destinos conforme regras. Use-o para distribuir eventos; SQS é uma fila de tarefas.
LEMBRETE
Escalar a API não escala automaticamente o banco. Primeiro meça onde o tempo e os erros se acumulam; depois amplie a camada que virou gargalo.
Documentação AWS: API Gateway · Application Load Balancer · EC2 Auto Scaling · CloudFront · RDS read replicas · EventBridge · SQS.
05 MODELOS · 8 MIN
Três decisões distintas.
Como elas se combinam?
Uma decisão define como partes se comunicam; outra organiza o código; a terceira define o que é publicado junto. Por isso, uma aplicação pode usar cliente-servidor, camadas e monólito modular ao mesmo tempo.
CLIENTE E SERVIDORDIAGRAMA
solicitação dados evento
MODELO DE COMUNICAÇÃO
Cliente-servidor
Web, app e painel chamam a mesma API; as regras não precisam ser copiadas para cada interface.
Problema que resolveWeb e app precisam usar as mesmas regras de acesso aos projetos.
Custo que assumeSe a rede ou a API falhar, os clientes perdem acesso às operações.
1Uma aplicação no servidor; muitos clientes podem se conectar.
RESUMO LADO A LADO← role para comparar →
| Modelo | Fronteira | Ajuda quando | Custo que aparece |
|---|---|---|---|
| Cliente-servidor | Comunicação pela rede | Web e app usam as mesmas regras | Rede ou servidor indisponível |
| Camadas | Responsabilidades no código | Regra de negócio isolada da tela e do banco | Dependências rígidas entre camadas |
| Monólito modular | Módulos dentro de um deploy | Limites internos com operação simples | Todos os módulos são publicados juntos |
| Microsserviços | Serviços e dados separados | Deploy e escala por capacidade | Rede, consistência e operação distribuídas |
EXEMPLO COMBINADO
Um ponto de partida comum: cliente-servidor na comunicação, camadas no código e um monólito modular em um único deploy. Microsserviços entram quando autonomia de deploy ou escala independente compensa o custo operacional.
Nota para apresentar
Pergunte qual mudança precisa ser independente: interface, código ou deploy. Compare o limite escolhido com o custo que aparece na tabela.
06 ARQUITETURA ORIENTADA A EVENTOS · 7 MIN
Uma coisa aconteceu.
Quem precisa saber?
Um evento registra um fato concluído. O produtor o publica; cada consumidor interessado reage por conta própria, sem o produtor conhecer todos os consumidores.
Um fato no passado: o projeto foi criado.
Um pedido: alguém deve criar um projeto.
Recebe e distribui mensagens. Pub-sub é o modelo em que vários consumidores podem receber o mesmo evento.
AJUDA QUANDO
Várias partes precisam reagir ao mesmo fato ou podem trabalhar sem resposta imediata.
CUSTA
O resultado pode demorar; por um período, partes diferentes podem mostrar estados distintos (consistência eventual). Mensagens podem falhar ou repetir; consumidores precisam tolerar repetições.
ESCOLHA
Se a tela precisa saber agora se o projeto foi criado, use uma resposta síncrona da API. Se notificações e auditoria podem reagir depois, publique um evento. Os dois estilos podem coexistir.
Eventos não significam guardar todo o histórico do sistema: arquitetura orientada a eventos não é automaticamente event sourcing. Azure Architecture Center · Event-driven architecture.
07 ATRIBUTOS DE QUALIDADE · 8 MIN
O sistema faz o quê?
E quão bem?
Um requisito funcional diz o que o sistema faz. Um atributo de qualidade diz como ele deve se comportar enquanto faz esse trabalho.
Listar projetos
A pessoa consulta os projetos a que tem acesso.
Responder rápido no pico
Com 500 requisições por segundo, menos de 1% de erros e 95% das respostas em até 300 ms.
TRANSFORME “RÁPIDO” EM UMA META VERIFICÁVEL
Defina a carga, o que será medido e o limite de sucesso.
p95 abaixo de 300 ms significa que 95 de cada 100 respostas chegam em menos de 300 ms. Carga e limites são exemplos; defina metas adequadas ao uso real.
OUTROS ATRIBUTOS QUE INFLUENCIAM A ARQUITETURA
Que comportamento o sistema precisa garantir?
Desempenho
Quanto tempo a operação leva sob a carga esperada? Exemplo: listar projetos em até 300 ms.
Disponibilidade
As funções essenciais continuam acessíveis quando uma parte falha? Notificações podem atrasar sem bloquear tarefas.
Segurança
Só pessoas autorizadas leem ou alteram os dados? A API confere o acesso ao projeto.
Facilidade de mudança
Uma mudança fica isolada? Trocar o provedor de notificações não altera as regras de tarefas.
Esses requisitos levam a decisões diferentes. Não existe uma técnica que melhore tudo sem custo.
EXEMPLOS DE DECISÕESBENEFÍCIO ↔ CUSTO
CacheLeituras repetidas ficam mais rápidas↔O dado guardado pode estar desatualizado
FilaRelatório longo não prende a chamada da API↔O resultado chega depois; exige operar um worker
RéplicasMais cópias atendem mais consultas↔Custam mais e podem ter dados atrasados
COMO DECIDIR
Escreva o comportamento esperado, defina como medir e só então escolha uma solução arquitetural. Assim, a equipe sabe se a decisão resolveu o problema.
Base: cenários de atributos de qualidade do Software Engineering Institute e Software Architecture in Practice.
08 MÓDULOS E DADOS · 6 MIN
Fronteiras entre módulos:
quem é dono dos dados?
Se Tarefas depende diretamente das tabelas de Projetos, uma mudança nelas pode quebrar outro módulo. Defina quem é dono dos dados e qual contrato os outros módulos usam.
Coesão
Regras relacionadas ficam juntas: Projetos cuida das regras de projetos.
Acoplamento
Quanto um módulo depende dos detalhes internos de outro. Prefira contratos estáveis.
✓ LIMITE EXPLÍCITO
PROJETOSé dono de projectsAPI: validar acesso
→TAREFASé dono de tasksusa o contrato de Projetos
Projetos grava projects; Tarefas mantém tasks e verifica acesso pelo contrato.
× LIMITE VAZADO
PROJETOStabela projects
↛TAREFASlê projects direto
Se a estrutura das tabelas de Projetos mudar, Tarefas quebra. A leitura direta também pode ignorar as regras de acesso.
REGRA PRÁTICA
Projetos e Tarefas podem usar o mesmo banco. Só Projetos grava projects; aplique esse limite no código e nas permissões do banco.
Parnas propõe esconder decisões sujeitas a mudança. Neste exemplo, a estrutura das tabelas fica atrás do contrato de Projetos: artigo de 1972.
09 EXPLICAR DECISÕES · 4 MIN
Como explicar
uma decisão?
Mostre só a estrutura necessária para responder à pergunta. Registre o motivo da escolha, as alternativas e os custos que ela cria.
DIAGRAMAS · DO GERAL AO ESPECÍFICO
C4 Model ↗Comece com as pessoas, sistemas e partes principais.
Aproxime o diagrama apenas quando uma conversa exigir mais detalhe.
ADR · REGISTRO DE DECISÃO
Exemplo: começar com um monólito modular
Uma nota curta ajuda a equipe a lembrar por que escolheu esse caminho.
Equipe pequena; regras compartilhadas; sem necessidade de deploy separado.
Uma aplicação, com módulos e contratos explícitos.
Serviços separados ou código sem fronteiras claras.
Operação simples; todos publicam juntos; limites precisam ser mantidos.
10 EXERCÍCIO · 6 MIN
Projeto criado.
Quem avisa o restante?
Cenário: a API deve confirmar a criação; notificação e auditoria podem acontecer logo depois.
DESAFIO01NO CHAT
?
Escolha A, B ou C. Diga o que a API faz antes de responder e que cuidado os consumidores precisam ter.
DINÂMICA ONLINEPeça votos no chat: “E se a mensagem atrasar ou chegar duas vezes?”
+ FONTES
Para continuar
estudando.
Definição de arquitetura, qualidade e diagramas.
ISO/IEC/IEEE 42010Architecture descriptionConceitos fundamentais, elementos, relações e princípios.
Software Engineering InstituteResults in Relating Quality AttributesComo tornar requisitos de qualidade mensuráveis.
C4 Model · Simon BrownDiagramas de arquiteturaVisões do sistema do contexto aos componentes.
Azure Architecture CenterEvent-driven architectureQuando usar produtores, canais e consumidores.
FIM DA AULARequisitos claros.
Requisitos claros.
Decisões justificadas.
Descreva as partes, suas relações, os requisitos que importam e os custos de cada decisão.
VOLTAR AO INÍCIO ↑