Arquitetura de Software
Conceitos
Arquitetura de software Define a estrutura geral do sistema: componentes, como se organizam e como se comunicam. É o esqueleto técnico.
Arquitetura de solução Olha o problema de negócio e monta o conjunto completo: sistemas, integrações, tecnologias e como tudo atende o objetivo final. É a visão macro da solução.
Design de software Detalha como cada parte interna do sistema funciona. Padrões, responsabilidades, fluxos. É o refinamento da arquitetura.
Design de código Lida com a escrita limpa e organizada do código. Nomes, funções, modularização, legibilidade. É o nível mais baixo, na prática.
O que é?
A Arquitetura de Software é a disciplina que define como um sistema deve ser estruturado e organizado para atender aos requisitos funcionais e não funcionais. Não existe uma definição única ou fechada. O próprio mercado resume assim:
“Arquitetura é sobre coisas importantes. Seja lá o que for.” — Ralph Johnson
“Coisas que as pessoas percebem que são difíceis de mudar.” — Martin Fowler
A arquitetura envolve decisões essenciais como:
Estilos arquiteturais
Padrões de arquitetura
Modelagem e estruturação dos dados
Organização interna dos componentes
Tecnologias e frameworks que serão a base do sistema
Requisitos não funcionais que sustentam a qualidade e o comportamento do sistema no longo prazo
Os requisitos não funcionais críticos são conhecidos como ilities, pois muitos terminam em “-ility”. Entre eles:
Availability
Reliability
Testability
Scalability
Security
Agility
Fault Tolerance
Elasticity
Recoverability
Performance
Deployability
Learnability
Maintainability
Observability
Interoperability
Extensibility
Portability
A mensagem central: arquitetura não é só sobre código — é sobre decisões estruturais que moldam o sistema e impactam tudo ao redor: operação, manutenção, evolução e até o negócio.
Leis
Duas leis se destacam e guiam praticamente toda decisão arquitetural:
1. Tudo na arquitetura de software é um trade-off Arquitetura sempre envolve compensações: ganhar algo de um lado implica perder algo do outro. Não existe solução perfeita — só escolhas com consequências.
Como dizem alguns nomes de peso:
“Não há respostas certas ou erradas em arquitetura — apenas trade-offs.” — Neal Ford
“Arquitetura é algo que você não pode pesquisar no Google.” — Mark Richards
“Programadores conhecem os benefícios de tudo e os trade-offs de nada. Arquitetos precisam entender ambos.” — Rich Hickey
Um desdobramento direto dessa lei: Se uma decisão parece não ter trade-off, é porque você ainda não identificou o lado negativo.
2. O “porquê” é mais importante que o “como” Arquitetura não começa pela ferramenta, linguagem ou padrão. Começa pela justificativa. Entender o motivo da decisão é o que separa escolhas conscientes de decisões aleatórias.
Responsabilidades e Perfil do Arquiteto de Software
O arquiteto é responsável por tomar decisões arquiteturais, analisar continuamente se a arquitetura ainda atende ao sistema e acompanhar tendências e inovações que possam impactar o projeto. Também precisa garantir que as decisões arquiteturais sejam seguidas e compreendidas pelo time, o que exige experiência diversificada e visão ampla.
A clássica pirâmide do conhecimento resume bem o perfil esperado:
Topo: coisas que você sabe
Meio: coisas que você sabe que não sabe
Base: coisas que você não sabe que não sabe
Além da parte técnica, o arquiteto deve compreender o domínio do negócio, ter habilidades interpessoais, saber negociar e lidar com desafios organizacionais. Grande parte do trabalho envolve alinhar pessoas e ideias, não apenas diagrama e código.
Embora o arquiteto nem sempre ocupe um cargo formal de liderança técnica, ele influencia diretamente decisões que afetam toda a empresa. Para que essas decisões funcionem na prática, é essencial boa comunicação e capacidade de influenciar sem recorrer à autoridade.
Alguns materiais tradicionais ajudam nesse desenvolvimento:
Fundamentals of Software Architecture (Mark Richards & Neal Ford) — traz técnicas e soft skills específicas para arquitetos.
97 Things Every Engineering Manager Should Know (Camille Fournier) — oferece insights úteis para quem quer fortalecer liderança técnica.
Como Fazer Amigos e Influenciar Pessoas (Dale Carnegie) — clássico sobre comunicação e influência, aplicável mesmo fora da tecnologia.
Em resumo: o papel do arquiteto mistura técnica, comunicação e entendimento do negócio — e nenhum desses aspectos pode ser ignorado.
Arquitetura de Solução
Arquitetura de Solução é a visão completa de como um sistema atende a uma necessidade de negócio, conectando tecnologia, integrações, requisitos e restrições externas. Enquanto a arquitetura de software foca dentro do sistema, a arquitetura de solução olha para tudo ao redor — sistemas externos, parceiros, regras, custos e viabilidade.
Ela considera, por exemplo, integrações como meios de pagamento, APIs de terceiros, sistemas logísticos e qualquer outra dependência que faça parte do fluxo de ponta a ponta.
Alguns pontos
Requisitos funcionais e não funcionais A solução deve atender ao que o negócio precisa fazer, mas também como deve se comportar — desempenho, segurança, disponibilidade, etc.
Esquemas Estruturas de dados, contratos de APIs, formatos de comunicação e como as informações trafegam entre os sistemas.
Viabilidade econômica e custo-benefício Avaliação prática: a solução faz sentido financeiramente? O custo de operar, integrar e manter é justificável?
Conformidade regulatória Atender leis, normas e regulações específicas do domínio — LGPD, PCI, auditorias, padrões de mercado.
Integração com parceiros e fornecedores A solução precisa encaixar bem com terceiros, respeitando contratos, SLAs, capacidades e limitações.
Governança Processos, regras e diretrizes que garantem consistência, segurança e alinhamento da solução com a estratégia da empresa.
Design de Software
Software Design
Enquanto a Arquitetura de Software define a estrutura geral do sistema, o design de software trata dos detalhes internos de cada componente. Ele descreve como classes, módulos, pacotes e serviços se organizam e se relacionam para implementar funcionalidades específicas, mantendo legibilidade, clareza e boa manutenção.
O design responde perguntas práticas como:
Como as classes e módulos serão organizados dentro do projeto?
Como aplicar os padrões de design adequados (ex.: Strategy, Factory, Observer)?
Como as entidades e serviços devem se comunicar internamente?
Como separar corretamente as camadas de código?
Como modelar as regras de negócio sem criar dependências desnecessárias?
Como lidar com dependências e modularidade para evitar acoplamento excessivo?
Como tornar o código mais manutenível, extensível e fácil de evoluir?
O design está um nível abaixo da arquitetura. A arquitetura cria o esqueleto; o design preenche os detalhes de como cada parte funciona por dentro.
Design de Código
Code Design
O design de código trabalha no nível mais granular da construção de software. É mais ligado à Engenharia de Software do que à Arquitetura. Enquanto a Arquitetura de Software define a estrutura do sistema e o Design de Software organiza os componentes internos, o Code Design cuida do código fonte em si — linha por linha, método por método.
Ele trata de como escrever código claro, estável e fácil de manter no longo prazo, aplicando boas práticas e padrões conhecidos.
Principais pontos:
Boas práticas de programação: Clean Code, SOLID, DRY, YAGNI
Legibilidade e organização do código
Formatação, estilo e padronização
Nomeação correta de classes, métodos e variáveis
Uso adequado de design patterns quando necessário
Estratégias de refatoração para manter o código saudável
Em resumo: Se a arquitetura define o esqueleto e o design de software define o funcionamento das partes, o design de código garante que cada parte seja escrita de forma clara e sustentável.
Estilos e Padrões Arquiteturais/ Padrões de Projeto
Quando falamos de soluções de software, existem três níveis de abordagem padronizada. Cada um atua em um grau diferente de abrangência:
Estilos Arquiteturais (Architectural Styles) – visão macro
Padrões Arquiteturais (Architectural Patterns) – organização interna
Padrões de Projeto (Design Patterns) – detalhes de implementação
Estilos Arquiteturais
Architectural Styles
São estruturas globais que definem o formato geral do sistema: topologia, fluxo de dados, escalabilidade e maneira como os componentes se distribuem.
Exemplos clássicos:
Cliente-Servidor
Arquitetura Monolítica
Microsserviços
Event-Driven
Pipe and Filter
Service-Oriented Architecture (SOA)
O estilo define a “forma” de alto nível do sistema.
Padrões Arquiteturais
Architectural Patterns
São maneiras específicas de organizar a aplicação por dentro, independente do estilo usado. Eles estruturam camadas, regras de comunicação e responsabilidades internas.
Exemplos:
Layered Architecture (camadas tradicionais)
Hexagonal Architecture (Ports and Adapters)
Clean Architecture
CQRS (Command Query Responsibility Segregation)
Event Sourcing
Enquanto os estilos definem o formato geral, os padrões arquiteturais definem o modelo interno de organização.
Padrões de Projeto
Design Patterns
Atuam no nível mais baixo, dentro do código e dos componentes. São soluções reutilizáveis para problemas comuns de design.
Exemplos:
Strategy
Factory Method / Abstract Factory
Singleton
Observer
Decorator
Adapter
Repository
São aplicados no código para melhorar reutilização, legibilidade e manutenção.
Livro “Design Patterns” (GoF)
O livro Design Patterns: Elements of Reusable Object-Oriented Software é a principal referência sobre padrões de projeto. Escrito por Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides, conhecidos como Gang of Four (GoF), ele organiza e descreve as soluções clássicas para problemas recorrentes no desenvolvimento orientado a objetos.
O livro define 23 padrões de projeto, divididos em três categorias:
Criação – maneiras de instanciar objetos (Factory, Builder, Singleton etc.)
Estruturais – como organizar classes e objetos (Adapter, Decorator, Composite etc.)
Comportamentais – como objetos interagem (Strategy, Observer, Command etc.)
Esses padrões influenciaram praticamente toda a engenharia de software moderna e continuam sendo base para decisões de design em qualquer linguagem orientada a objetos.
Diagramas Arquiteturais Formais
Quando falamos de arquitetura de software, diagramas não são ilustração. São linguagem técnica. Ajudam a comunicar decisões, limites e responsabilidades. O ponto é simples: clareza supera beleza.
Existem três abordagens principais para diagramação: padrões formais, modelos estruturados (C4) e diagramas ad-hoc.
1. Padrões Formais de Diagramação
Os padrões formais surgiram para reduzir ambiguidade. O mais conhecido é a UML (Unified Modeling Language).
UML
A UML tenta padronizar como você representa comportamento, componentes e relacionamentos. Exemplos clássicos:
Diagrama de classes: mostra entidades e seus relacionamentos.
Diagrama de sequência: mostra interações ao longo do tempo.
Diagrama de componentes: mostra os blocos da aplicação.
UML funciona quando você precisa de precisão, especialmente em equipes grandes. Mas é comum exagero: diagramas gigantes que ninguém lê. Use com parcimônia.
2. C4 Model
O C4 Model surgiu como resposta à complexidade da UML. É direto, hierárquico e fala a língua da engenharia moderna.
Os quatro níveis:
1. Context (Contexto)
Mostra o sistema e quem interage com ele. É o diagrama que qualquer executivo consegue entender.
2. Container
Aqui você divide o sistema em blocos executáveis: APIs, front-end, banco, serviços. Foco: responsabilidades e comunicações.
3. Component
Quebramos cada container em partes internas. Ex.: dentro do serviço “Pedidos”, você tem “Cadastro”, “Pagamento”, “Notificação”.
4. Code
O nível mais detalhado. Diagramas de classes ou estrutura interna do módulo. Pouca gente chega até aqui porque nem sempre é necessário.
A virtude do C4 é ser prático e escalável. Serve para documentar hoje sem virar peso morto amanhã.
3. Diagramas ad-hoc
São diagramas construídos sem seguir padrões formais. Simples, rápidos, úteis para rascunhar ideias. Podem ser:
fluxos desenhados no quadro,
caixas e setas genéricas,
esquemas conceituais improvisados.
Funcionam bem em fases iniciais, mas não substituem uma documentação final.
Guidelines para uma boa diagramação
Alguns princípios não mudam:
1. Diagramas de baixa fidelidade
Não precisa usar arte sofisticada. O que manda é clareza. Rabisco simples, alinhado, é melhor que uma obra de arte confusa.
2. Evite apego irracional ao artefato
Diagrama não é contrato. Quando a arquitetura mudar, o diagrama muda. O erro clássico é criar um diagrama “bonito” e nunca mais atualizar.
3. Mostre só o necessário
Excesso de detalhe só afasta quem precisa entender.
4. Padronize
Escolha um estilo e mantenha. Misturar convenções cria ruído.
"Quanto mais tempo e esforço você investir no planejamento ou em um documento, maior será a probabilidade de você proteger o que está contido no plano ou documento, mesmo diante de evidências de que ele é impreciso ou desatualizado." — Neal Ford e outros
Essa frase expõe um problema clássico em arquitetura de software: o apego ao documento. Quando alguém investe tempo demais produzindo um diagrama ou plano extremamente detalhado, cria-se uma barreira psicológica para mudar aquilo depois — mesmo quando a realidade já mostrou que o artefato está errado, incompleto ou ultrapassado.
Arquitetura é dinâmica. Sistemas mudam. Requisitos mudam. Informações mudam. Por isso, a preocupação deve ser manter a documentação útil, não perfeita.
A mensagem é simples: não gaste energia demais em artefatos que precisam evoluir. Faça o necessário para comunicar, revise quando o sistema mudar e não defenda diagramas como se fossem leis imutáveis.
Isso vale tanto para UML, quanto para C4, quanto para qualquer diagrama ad-hoc. O foco não é a estética ou o nível de detalhe, mas a clareza e a utilidade prática.
Ferramentas para Diagramação
Algumas ferramentas se destacam por praticidade ou precisão:
StarUML – mais técnico e estruturado; ideal para UML formal.
Whimsical – rápido, limpo, fácil para diagramas de baixa fidelidade.
Miro – colaborativo, ótimo para equipes.
Excalidraw – estilo rascunho, simples e direto.
Draw.io (diagrams.net) – gratuito e flexível.
Eraser.io – focado em fluxos e diagramas simples.
Lucidchart – profissional e robusto, muito usado corporativamente.
Documentações Arquiteturais: Design Docs e ADRs
Documentação arquitetural não é enfeite. Ela existe para registrar decisões, fundamentar escolhas e manter clareza técnica ao longo da vida do sistema. Aqui entram dois tipos de artefatos essenciais: Design Docs e ADRs.
Design Docs
O Design Doc é um documento que justifica como uma solução técnica será construída e por quê. Ele é usado antes da implementação, quando existe uma decisão importante a ser tomada.
Pontos centrais:
Explica o problema.
Apresenta alternativas.
Compara prós e contras.
Justifica a decisão final.
Define o impacto na arquitetura.
Alinha todos antes do código começar.
Um bom Design Doc não é longo. É claro, objetivo e pragmático. Ele documenta raciocínio, não decoração.
Exemplo
Design Doc — Adoção de Arquitetura de Microsserviços
1. Contexto e Problema
O e-commerce está crescendo rapidamente e a aplicação monolítica atual não acompanha a complexidade exigida. Hoje, funcionalidades como catálogo, carrinho, pagamentos e pedidos estão todas dentro de um único código. Isso gera problemas claros:
Escalabilidade limitada: todo o sistema precisa escalar junto, mesmo quando apenas um módulo sofre pressão de tráfego.
Deploys arriscados: qualquer alteração exige redeploy completo, aumentando risco de falha.
Baixa flexibilidade tecnológica: tudo depende da mesma stack, impedindo evolução independente.
Para resolver esses pontos, propõe-se a adoção de arquitetura baseada em microsserviços.
2. Objetivos
Permitir escalabilidade independente por domínio.
Facilitar implantação contínua (CI/CD) e reduzir MTTR.
Aumentar resiliência isolando falhas.
Permitir uso de tecnologias adequadas a cada serviço.
Suportar crescimento acelerado sem impactos globais.
3. Arquitetura Proposta
3.1 Divisão de Serviços
A aplicação será decomposta em serviços independentes:
Serviço de Catálogo: produtos, descrições, preços.
Serviço de Carrinho: itens adicionados ao carrinho.
Serviço de Pagamentos: processamento de transações.
Serviço de Pedidos: status, histórico e controle de pedidos.
Serviço de Notificações: envio de e-mails e mensagens.
3.2 Comunicação
Assíncrona (preferencial): eventos via Apache Kafka, diminuindo acoplamento temporal.
Síncrona: REST para operações que exigem resposta imediata.
3.3 Bancos de Dados
Cada serviço possui seu banco de dados próprio, sem compartilhamento direto. Garante autonomia e isolamento.
4. Alternativas Consideradas e Trade-offs
Arquitetura Monolítica
Simplicidade inicial; menor esforço operacional.
Escalabilidade difícil; deploys complexos; falhas afetam todo o sistema.
Microsserviços
Escalabilidade, flexibilidade, resiliência.
Maior complexidade operacional; necessidade de observabilidade.
Modular Monolítico
Melhor organização interna; manutenção facilitada.
Ainda sofre limitações de escalabilidade e deploy integrado.
5. Impacto Esperado
Organizacional
Equipes mais autônomas, menos dependências internas e fluxo de entrega mais rápido.
Operacional
Evolução contínua do sistema, facilidade para incluir novas funcionalidades e menor risco de regressões.
Financeiro
Escalabilidade seletiva reduz custos de infraestrutura ao evitar escalonamento desnecessário de toda a aplicação.
6. Riscos e Desafios
Complexidade operacional: exige observabilidade, monitoração, tracing e logging distribuído.
Gerenciamento de dados distribuídos: necessidade de boas práticas para evitar inconsistências.
Latência: chamadas remotas geram overhead; pode exigir caching e comunicação assíncrona.
Curva de aprendizado: equipe precisará se adaptar à arquitetura distribuída e ferramentas relacionadas.
7. Plano de Implementação
Fase 1: separar o Serviço de Pagamentos como primeiro microsserviço, validando integração com gateways.
Fase 2: extrair módulos de Pedidos e Notificações.
Fase 3: continuar a decomposição gradual do monólito até contemplar os demais domínios.
ADRs (Architecture Decision Records)
O ADR registra uma decisão arquitetural específica e o contexto que levou a ela. Diferente do Design Doc, o ADR é curto e direto.
Estrutura típica:
Contexto — o que motivou a decisão.
Decisão — o que foi escolhido.
Consequências — impactos positivos e negativos.
ADRs são úteis porque deixam rastro: no futuro, quando alguém se perguntar “por que fizemos isso desse jeito?”, a resposta estará ali. Simples, histórico, rastreável.
Exemplo
ADR-001 – Adoção do Apache Kafka para Comunicação Assíncrona Entre Serviços
Contexto
Hoje, os serviços do e-commerce dependem de chamadas REST síncronas. Isso causa problemas conhecidos:
Latência alta: um serviço trava esperando o outro responder.
Baixa resiliência: se um serviço cai ou demora, o restante sofre.
Escalabilidade limitada: tudo fica acoplado, e qualquer aumento de carga derruba o desempenho.
A necessidade é clara: adotar mensageria para comunicação assíncrona, reduzindo dependências diretas entre serviços.
Decisão
A solução escolhida é Apache Kafka como barramento de eventos para comunicação assíncrona entre os serviços.
Motivos da Decisão
Escalabilidade real: consumidores paralelos, múltiplas partições e distribuição de carga.
Persistência de eventos: permite reprocessamento sem gambiarras.
Alto throughput: feito para tráfego pesado, sem degradação.
Desacoplamento total: produtor e consumidor não precisam existir no mesmo instante.
Alternativas Consideradas
RabbitMQ
Simples, filas com prioridade
Não guarda eventos por padrão; não acompanha Kafka em throughput
Amazon SQS/SNS
Gerenciado; fácil
Latência maior; custo por mensagem
REST síncrono
Simples e conhecido
Alto acoplamento; falha de um derruba tudo
Dado o cenário, Kafka entrega o que o sistema precisa: resiliência, volume e futuro sem gargalos.
Impactos
Arquitetura: serviços passam a publicar/consumir tópicos Kafka em vez de chamadas diretas.
Transações: será necessário implementar idempotência nos consumidores.
Monitoramento: inclusão de métricas para consumo, falhas e lags.
Equipe: treinamento básico em tópicos, partições, grupos de consumo e boas práticas.
Status
Aprovado em: 14/02/2025
Aprovadores: João das Couves (Tech Lead), Manoel (Arquiteto), Maria Abadia (Engenheira Sênior)
Links úteis
A lista abaixo serve como referência rápida para estudo e criação dos seus próprios documentos:
O que é System Design e System Design Interview?
System Design
System Design é o processo de projetar a arquitetura completa de um sistema. É onde se define como tudo vai funcionar: componentes, comunicação, dados, escalabilidade, segurança e operação.
É o “esqueleto” que sustenta qualquer software sério.
Ele responde perguntas como:
Como o sistema aguenta milhões de usuários?
Como os serviços falam entre si?
Como os dados são armazenados e replicados?
Como garantir resiliência quando algo inevitavelmente falhar?
Como escalar sem virar um Frankenstein?
System Design é disciplina clássica de engenharia: entender requisitos, escolher padrões, aplicar trade-offs, manter simplicidade e prever o futuro.
System Design Interview
A System Design Interview é o formato usado para avaliar se o candidato sabe pensar como um engenheiro de sistemas.
Não é sobre decorar termos. É sobre raciocínio, trade-offs e clareza.
Na prática, a entrevista cobra:
Entender e delimitar o problema O candidato define escopo, restrições, volume, usuários, limites.
Propor uma arquitetura de alto nível Componentes principais, comunicação, fluxo de dados.
Discutir decisões técnicas Banco relacional vs. NoSQL, cache, filas, proxies, sharding, particionamento.
Escalabilidade e resiliência Como escalar leitura, escrita, storage, tráfego.
Detalhar partes críticas API, banco, filas, consistência, índices, balanceadores, segurança.
Trade-offs claros O que ganha e o que perde em cada decisão.
A entrevista mede maturidade, não adivinhação.
Comparação
Tema
System Design
System Design Interview
Propósito
Projetar sistemas reais.
Avaliar se o candidato sabe projetar sistemas.
Foco
Arquitetura, componentes, comunicação, dados, escalabilidade, resiliência.
Raciocínio, trade-offs, clareza, tomada de decisão.
Contexto
Trabalho diário de engenharia.
Prova prática de arquitetura em tempo limitado.
Escopo
Completo e profundo, envolvendo decisões técnicas reais.
Alto nível, cobrindo pontos essenciais rapidamente.
Resultado
Arquitetura implementável.
Avaliação do nível do candidato.
Links úteis
ByteByteGo – System Design Interview Uma das melhores referências modernas, direta e objetiva sobre arquitetura de sistemas de grande escala.
Desafio - Refletindo sobre características arquiteturais
A arquitetura de software envolve decisões estratégicas para garantir que um sistema alcance os requisitos funcionais e não funcionais desejados.
No entanto, como vimos, não existe uma definição única e rígida sobre o que é arquitetura de software.
Tarefa
1. Pense em um sistema ou aplicativo que você usa no dia a dia (pode ser um app de delivery, rede social, internet banking, etc).
2. Quais características arquiteturais desse sistema podem ser importantes? Por exemplo: ele precisa ser rápido? Precisa ser escalável? Suportar muitos usuários ao mesmo tempo? Ser seguro? Funcionar offline? Há outras características que você considera importantes?
Dica: Você não precisa saber como a arquitetura foi feita, mas tente imaginar quais desafios arquiteturais os desenvolvedores desse sistema tiveram que considerar.
Use seu portfólio de conhecimento e pesquise o que ainda não sabe, mas não se preocupe em ter a resposta "perfeita" neste momento.
Last updated