Introdução
Não existe um padrão arquitetural capaz de resolver todos os problemas.
Cada arquitetura possui:
- Vantagens
- Limitações
- Custos
- Riscos
- Consequências de longo prazo
Essas trocas são chamadas de trade-offs.
O objetivo do arquiteto não é encontrar uma arquitetura perfeita, mas escolher conscientemente a solução mais adequada ao contexto do projeto, do time e do negócio.
A melhor arquitetura não é necessariamente a mais moderna ou sofisticada.
É aquela que resolve o problema atual sem impedir desnecessariamente a evolução futura.
Objetivos de aprendizagem
- Comparar padrões arquiteturais por contexto, custo e risco.
- Reconhecer quando a complexidade de um padrão é desproporcional.
- Explicitar trade-offs em vez de apresentar recomendações absolutas.
O que deve orientar a escolha
A escolha arquitetural precisa considerar dimensões relacionadas, sem reduzi-las a uma lista única.
Contexto de produto e entrega
- Requisitos funcionais e crescimento esperado do produto
- Prazo de entrega
- Custo de desenvolvimento e infraestrutura
Capacidade da organização
- Tamanho e experiência do time
- Manutenibilidade
- Complexidade operacional
Atributos de qualidade
- Escalabilidade e desempenho
- Segurança
- Disponibilidade
- Demais requisitos não funcionais prioritários
Um padrão tecnicamente adequado pode ser inviável quando o time não possui conhecimento ou estrutura para operá-lo.
Da mesma forma, uma solução inicialmente simples pode se tornar insuficiente quando o produto cresce ou passa a atender requisitos mais rigorosos.
Arquitetura monolítica
Na arquitetura monolítica, os principais componentes da aplicação são construídos e implantados como uma única unidade.
Interface, regras de negócio e acesso a dados podem estar no mesmo projeto e no mesmo processo de execução.
Quando faz sentido
O monólito tende a ser adequado para:
- Equipes pequenas
- Produtos em fase inicial
- MVPs
- Startups validando uma ideia
- Sistemas com domínio ainda pouco conhecido
- Projetos sem necessidade inicial de escala independente
Vantagens
- Desenvolvimento inicial mais simples
- Menor quantidade de infraestrutura
- Deploy centralizado
- Comunicação interna rápida
- Menor custo operacional inicial
- Facilidade para depuração local
- Menor complexidade distribuída
- Boa velocidade para validar um produto
Limitações
- Escalabilidade pouco granular
- Uma falha pode afetar toda a aplicação
- Crescimento do acoplamento interno
- Deploys maiores e potencialmente mais arriscados
- Dificuldade para utilizar tecnologias diferentes
- Aumento do tempo de build e testes
- Dificuldade de divisão entre vários times conforme o sistema cresce
Monólito não significa código desorganizado
Uma aplicação monolítica pode possuir:
- Módulos bem definidos
- Separação de responsabilidades
- Baixo acoplamento
- Interfaces internas claras
- Testes automatizados
- Regras de dependência
Esse modelo é frequentemente chamado de monólito modular.
Muitas aplicações podem começar dessa maneira antes de considerar a distribuição em serviços independentes.
Arquitetura em camadas
A arquitetura em camadas organiza o sistema de acordo com responsabilidades.
Uma divisão comum é:
- Camada de apresentação
- Camada de aplicação
- Camada de negócio ou domínio
- Camada de acesso a dados
- Infraestrutura
Cada camada utiliza serviços oferecidos por outra camada.
Vantagens
- Separação clara de responsabilidades
- Melhor organização do código
- Maior testabilidade
- Manutenção mais previsível
- Possibilidade de trabalho paralelo
- Facilidade para substituir partes da infraestrutura
- Estrutura familiar para muitos desenvolvedores
Limitações
- Dependência entre camadas adjacentes
- Risco de regras de negócio espalhadas
- Excesso de chamadas entre camadas
- Aumento da quantidade de mapeamentos
- Possível aumento de latência em ambientes distribuídos
- Alterações simples atravessando várias camadas
- Possibilidade de uma estrutura excessivamente rígida
Arquitetura lógica e implantação
Arquitetura em camadas não determina obrigatoriamente como o sistema será implantado.
Uma aplicação organizada em camadas pode ser:
- Um monólito
- Um conjunto de serviços
- Uma aplicação distribuída
As camadas representam uma organização lógica. A implantação representa uma decisão física e operacional.
Clean Architecture
A Clean Architecture organiza o sistema ao redor das regras de negócio.
Seu princípio central é a regra de dependência:
As camadas externas podem conhecer as internas, mas o domínio não deve depender diretamente de:
- Frameworks
- Bancos de dados
- Interfaces gráficas
- Serviços externos
- Bibliotecas de infraestrutura
Uma organização comum inclui:
- Entidades
- Casos de uso
- Adaptadores de interface
- Frameworks e infraestrutura
Vantagens
- Regras de negócio isoladas
- Alta testabilidade
- Menor dependência de frameworks
- Facilidade para substituir infraestrutura
- Melhor organização de sistemas complexos
- Possibilidade de trabalho paralelo
- Maior proteção do domínio
Limitações
- Complexidade inicial maior
- Mais interfaces, classes e arquivos
- Curva de aprendizagem
- Necessidade de mapeamentos
- Desenvolvimento inicial mais demorado
- Risco de overengineering
- Estrutura excessiva para aplicações simples
Quando utilizar
Ela tende a fazer mais sentido quando:
- O domínio possui regras complexas
- O produto terá vida longa
- Existem várias integrações
- A infraestrutura pode mudar
- Testabilidade é uma prioridade
- O domínio precisa permanecer protegido de detalhes externos
Arquitetura hexagonal
A arquitetura hexagonal também é conhecida como Ports and Adapters.
Ela separa o núcleo da aplicação dos elementos externos.
Núcleo
Contém:
- Regras de negócio
- Casos de uso
- Entidades
- Comportamentos do domínio
Portas
As portas definem contratos de entrada e saída.
Exemplos:
- Serviço de pagamento
- Repositório de clientes
- Caso de uso para criação de pedido
- Serviço de envio de mensagens
Adaptadores
Os adaptadores conectam o sistema a tecnologias externas.
Exemplos:
- Controller HTTP
- Banco de dados
- Fila
- Interface de linha de comando
- API externa
- Serviço de e-mail
Vantagens
- Isolamento do domínio
- Testes unitários mais simples
- Independência da infraestrutura
- Facilidade para oferecer múltiplas interfaces
- Substituição de integrações com menor impacto
- Reutilização das mesmas regras de negócio
Limitações
- Mais abstrações
- Necessidade de mapear modelos
- Curva de aprendizagem
- Grande quantidade de portas e adaptadores
- Estrutura desnecessária para sistemas pequenos
- Maior esforço inicial
Clean Architecture e arquitetura hexagonal
As duas abordagens possuem objetivos semelhantes:
- Isolar regras de negócio
- Inverter dependências
- Evitar dependência direta de frameworks
- Facilitar testes
- Separar domínio e infraestrutura
A diferença principal está na forma como essa separação é representada.
| Clean Architecture | Arquitetura hexagonal |
|---|---|
| Representada por círculos ou camadas | Representada por núcleo, portas e adaptadores |
| Destaca a direção das dependências | Destaca a comunicação com o mundo externo |
| Utiliza entidades e casos de uso | Utiliza domínio, portas e adaptadores |
| Enfatiza a regra de dependência | Enfatiza interfaces de entrada e saída |
Elas não são necessariamente concorrentes.
Um sistema pode combinar princípios das duas abordagens.
Microkernel
A arquitetura Microkernel possui um núcleo mínimo e extensões conectadas por plugins.
Núcleo
Contém as funcionalidades essenciais e estáveis.
Plugins
Adicionam comportamentos específicos sem modificar significativamente o núcleo.
Exemplos de uso
- Ambientes de desenvolvimento
- Navegadores
- Plataformas de e-commerce
- Sistemas empresariais configuráveis
- Aplicações com módulos opcionais
- Ferramentas extensíveis
Vantagens
- Extensibilidade
- Núcleo estável
- Funcionalidades opcionais
- Personalização
- Implantação de recursos por plugins
- Separação entre funcionalidades essenciais e adicionais
Limitações
- Compatibilidade entre versões
- Complexidade dos contratos
- Risco de plugins inseguros ou instáveis
- Gerenciamento de dependências
- Dificuldade em testes integrados
- Limitações impostas pelo núcleo
Space-Based Architecture
A Space-Based Architecture busca eliminar gargalos causados por um banco de dados central.
Os dados e o processamento são distribuídos entre módulos, frequentemente utilizando memória distribuída.
Componentes possíveis
- Unidades de processamento
- Grid de dados em memória
- Middleware de mensageria
- Sincronização de estado
- Persistência assíncrona
- Módulos independentes de processamento
Vantagens
- Escalabilidade extrema
- Alto desempenho
- Baixa latência
- Distribuição do processamento
- Redução do gargalo central
- Alta disponibilidade
- Processamento assíncrono
- Isolamento parcial de falhas
Limitações
- Design distribuído complexo
- Sincronização de dados
- Alto consumo de memória
- Dificuldade com transações
- Consistência mais difícil de garantir
- Complexidade de persistência
- Maior custo de infraestrutura
- Necessidade de forte observabilidade
Quando pode ser adequada
- Sistemas com enorme volume de transações
- Plataformas de negociação
- Jogos on-line
- Processamento em tempo real
- Sistemas com picos extremos
- Aplicações em que o banco central se tornou um gargalo
Event-Driven Architecture
Na arquitetura orientada a eventos, componentes se comunicam pela produção e pelo consumo de eventos.
Um evento representa algo que já aconteceu.
Exemplos:
PedidoCriadoPagamentoAprovadoClienteCadastradoEstoqueAtualizadoConsentimentoRevogado
Componentes principais
Produtor
Publica um evento.
Broker ou barramento
Transporta e distribui os eventos.
Exemplos citados:
- Kafka
- RabbitMQ
- Amazon EventBridge
- Amazon SNS e SQS
- Azure Event Grid
Consumidor
Recebe o evento e executa uma ação.
Vantagens
- Baixo acoplamento
- Escalabilidade independente
- Processamento assíncrono
- Maior resiliência
- Facilidade para adicionar consumidores
- Evolução independente dos componentes
- Respostas mais rápidas em operações não bloqueantes
Limitações
- Consistência eventual
- Fluxos mais difíceis de rastrear
- Depuração complexa
- Necessidade de idempotência
- Gerenciamento de contratos
- Possibilidade de mensagens duplicadas
- Dependência da infraestrutura de eventos
- Dificuldade de ordenação
- Tratamento de falhas mais complexo
Idempotência
Processar o mesmo evento mais de uma vez não deve gerar efeitos incorretos.
Por exemplo, o recebimento duplicado de um evento de pagamento não pode gerar duas cobranças.
Consistência eventual
Os dados podem não ficar sincronizados imediatamente, mas convergem após algum tempo.
Dead-letter queue
Fila utilizada para armazenar mensagens que não puderam ser processadas corretamente.
Correlação
Identificadores de correlação ajudam a rastrear uma operação por vários eventos e serviços.
Cell-Based Architecture
Na arquitetura baseada em células, o sistema é dividido em unidades independentes chamadas células.
Cada célula pode conter:
- Aplicação
- Dados
- Processamento
- Serviços
- Infraestrutura
- Recursos de comunicação
As células podem executar as mesmas funcionalidades para diferentes:
- Grupos de usuários
- Regiões
- Clientes
- Conjuntos de dados
Vantagens
- Isolamento de falhas
- Redução do raio de impacto
- Escalabilidade modular
- Implantação independente
- Isolamento de dados
- Evolução gradual
- Possibilidade de adicionar células
- Maior resiliência
Limitações
- Gerenciamento complexo
- Duplicação de infraestrutura
- Descoberta de serviços
- Comunicação entre células
- Transações distribuídas
- Controle de versões
- Maior custo operacional
- Necessidade de automação madura
Exemplo
Uma plataforma pode separar clientes entre diferentes células.
Se uma célula apresentar falha, apenas uma parcela dos usuários será afetada, em vez de toda a plataforma.
Microsserviços
A arquitetura de microsserviços divide o sistema em serviços pequenos e autônomos, organizados ao redor de capacidades de negócio.
Cada serviço pode possuir:
- Código próprio
- Processo próprio
- Banco de dados próprio
- Pipeline de implantação
- Escalabilidade independente
- Equipe responsável
Vantagens
- Implantação independente
- Escalabilidade específica
- Autonomia dos times
- Isolamento de responsabilidades
- Possibilidade de tecnologias diferentes
- Redução do impacto de determinadas mudanças
- Evolução independente dos domínios
Limitações
- Comunicação distribuída
- Consistência eventual
- Observabilidade mais difícil
- Mais infraestrutura
- Testes integrados complexos
- Gerenciamento de versões
- Segurança entre serviços
- Falhas de rede
- Transações distribuídas
- Maior custo operacional
Esse custo adicional pode ser chamado de imposto dos sistemas distribuídos.
Ele inclui:
- Rede
- Latência
- Mensageria
- Observabilidade
- Segurança
- Automação
- Orquestração
- Consistência
- Tratamento de falhas
Uma equipe pequena pode acabar investindo mais tempo administrando a arquitetura do que entregando valor.
SOA
A Service-Oriented Architecture organiza sistemas como serviços reutilizáveis e integrados.
Ela é comum em ambientes empresariais que precisam conectar:
- Sistemas legados
- ERPs
- CRMs
- Plataformas internas
- Sistemas de parceiros
- Aplicações de diferentes departamentos
Características
- Serviços com contratos definidos
- Integração entre sistemas
- Reutilização de capacidades
- Governança central
- Possível utilização de Enterprise Service Bus
- Comunicação por padrões corporativos
SOA e microsserviços
| SOA | Microsserviços |
|---|---|
| Integração de sistemas empresariais | Divisão por capacidades de negócio |
| Governança geralmente centralizada | Times mais autônomos |
| Serviços frequentemente maiores | Serviços menores e mais específicos |
| Pode utilizar barramento central | Favorece comunicação descentralizada |
| Ênfase em reutilização corporativa | Ênfase em autonomia e implantação independente |
A fronteira entre os conceitos não é sempre absoluta.
Comparação resumida
| Arquitetura | Melhor cenário | Principal vantagem | Principal custo |
|---|---|---|---|
| Monolítica | MVP e equipes pequenas | Simplicidade | Escala e deploy menos independentes |
| Camadas | Sistemas empresariais tradicionais | Organização | Rigidez e acoplamento |
| Clean | Domínio complexo e produto duradouro | Independência tecnológica | Complexidade inicial |
| Hexagonal | Sistemas com várias integrações | Isolamento do domínio | Abstrações e mapeamentos |
| Microkernel | Sistemas extensíveis | Plugins e personalização | Gestão de compatibilidade |
| Space-Based | Altíssimo volume transacional | Escala e baixa latência | Estado distribuído |
| Event-Driven | Processos assíncronos | Desacoplamento | Consistência eventual |
| Cell-Based | Plataformas de grande escala | Isolamento de falhas | Duplicação e governança |
| Microsserviços | Muitos times e domínios independentes | Autonomia | Complexidade distribuída |
| SOA | Integração corporativa | Reutilização de serviços | Governança e centralização |
Como escolher um padrão arquitetural
A escolha deve começar pelo problema, não pelo padrão.
Perguntas sobre o negócio
- Qual valor o sistema entrega?
- Quanto uma indisponibilidade pode custar?
- Existe prazo crítico para o lançamento?
- O produto ainda está sendo validado?
- Qual é o crescimento esperado?
Perguntas sobre o sistema
- Qual é o volume de usuários?
- Existem picos de acesso?
- Qual é a latência aceitável?
- Os dados precisam de consistência imediata?
- Quais partes precisam escalar?
- Existem integrações externas?
Perguntas sobre o time
- Quantas pessoas trabalharão no projeto?
- O time conhece sistemas distribuídos?
- Existe uma equipe de infraestrutura?
- A empresa possui maturidade de observabilidade?
- Há capacidade para operar a solução?
Perguntas sobre custos
- Quanto custa construir?
- Quanto custa manter?
- Quanto custa evoluir?
- Quanto custa monitorar?
- O retorno justifica a complexidade?
ROI aplicado às decisões arquiteturais
O retorno sobre investimento não deve considerar apenas o custo inicial.
Uma decisão arquitetural precisa avaliar o custo total de:
- Construção
- Infraestrutura
- Manutenção
- Monitoramento
- Segurança
- Equipe
- Incidentes
- Evolução
- Treinamento
- Migração futura
Uma arquitetura altamente sofisticada pode possuir excelente qualidade técnica, mas baixo retorno quando o negócio não precisa dela.
Exemplo
Criar dez microsserviços para um MVP mantido por três desenvolvedores pode aumentar:
- Tempo de entrega
- Custo de nuvem
- Complexidade dos testes
- Esforço operacional
- Quantidade de incidentes
Nesse contexto, um monólito modular pode entregar um ROI maior.
Latência
Latência representa o tempo necessário para uma solicitação percorrer o sistema e produzir uma resposta.
Ela pode ser influenciada por:
- Chamadas de rede
- Banco de dados
- Filas
- Serviços externos
- Processamento
- Serialização
- Criptografia
- Distância geográfica
- Quantidade de serviços envolvidos
Em um monólito, muitas chamadas acontecem em memória.
Em microsserviços, uma única operação pode atravessar diferentes serviços e redes.
A distribuição pode aumentar a escalabilidade, mas também aumentar a latência.
Os três pilares mencionados na aula
As anotações registram a existência de três pilares, mas apenas dois foram identificados claramente:
- ROI e custo: quanto custa criar, manter e evoluir em comparação ao retorno gerado.
- Latência: quanto tempo o sistema demora para responder.
- Terceiro pilar: não foi registrado nas anotações.
Inteligência artificial e arquitetura
A adoção de inteligência artificial também exige decisões arquiteturais.
Não basta integrar uma API e considerar o problema resolvido.
Treinamento de modelos
Treinar um modelo pode exigir:
- Grandes volumes de dados
- GPUs
- Pipelines de processamento
- Limpeza e classificação de dados
- Versionamento de datasets
- Registro de modelos
- Avaliação de qualidade
- Monitoramento
- Controle de custos
- MLOps
O arquiteto precisa avaliar se a empresa deve:
- Treinar um modelo próprio
- Ajustar um modelo existente
- Utilizar um serviço externo
- Combinar modelos com regras tradicionais
Arquitetura de agentes
Um agente pode utilizar modelos para tomar decisões, consultar ferramentas e executar tarefas.
Uma arquitetura desse tipo pode conter:
- Modelo de linguagem
- Orquestrador
- Prompts e instruções
- Memória
- Banco vetorial
- APIs e ferramentas
- Autenticação
- Controle de permissões
- Guardrails
- Auditoria
- Aprovação humana
Riscos
- Respostas incorretas
- Execução de ações indevidas
- Vazamento de dados
- Uso excessivo de recursos
- Custos imprevisíveis
- Dependência de fornecedores
- Ataques por prompt injection
IA aplicada a logs e observabilidade
Um agente pode utilizar logs, métricas e rastreamentos para apoiar a operação do sistema.
Possíveis aplicações:
- Resumir incidentes
- Identificar anomalias
- Correlacionar erros
- Encontrar padrões
- Sugerir possíveis causas
- Consultar runbooks
- Recomendar ações
- Priorizar alertas
- Explicar cadeias de falhas
Esse uso pode ser associado a práticas de AIOps.
Exemplo de fluxo
Aplicação envia logs e métricas
↓
Plataforma centraliza os dados
↓
Agente consulta as informações
↓
IA identifica possíveis correlações
↓
Agente apresenta um diagnóstico
↓
Pessoa valida a recomendação
↓
Correção é executada manualmente ou por automação controladaCuidados
- Remover dados sensíveis dos logs
- Restringir permissões do agente
- Registrar todas as ações
- Validar recomendações críticas
- Evitar execução autônoma irrestrita
- Avaliar custo por consulta
- Manter supervisão humana
Verifique seu entendimento
Qual é o primeiro critério para escolher um padrão arquitetural?
Conclusão
Arquitetura é uma escolha contextual.
Um monólito pode ser a melhor solução para validar rapidamente uma ideia.
Uma arquitetura orientada a eventos pode ser adequada para processos assíncronos.
Uma arquitetura baseada em células pode reduzir o impacto de falhas em plataformas de grande escala.
Clean Architecture e arquitetura hexagonal podem proteger regras de negócio complexas.
Nenhuma dessas abordagens é automaticamente superior.
A decisão precisa equilibrar:
- Valor para o negócio
- ROI
- Custo
- Latência
- Escalabilidade
- Segurança
- Resiliência
- Capacidade do time
- Tempo de entrega
- Facilidade de evolução
Arquitetura de software é a arte de escolher conscientemente quais dificuldades o sistema está preparado para enfrentar.
Desafio de decisão
Qual abordagem é mais coerente para um MVP com time pequeno?
A escala inicial é baixa, os requisitos mudam semanalmente e a equipe ainda não possui plataforma de operação distribuída.
A recomendação considera apenas este contexto; mudanças nas restrições podem mudar a decisão.
Revisão do artigo
Pontos principais
- — Nenhum padrão é superior fora de um contexto.
- — Complexidade técnica e operacional também faz parte do custo.
- — Limites claros preservam opções mesmo em arquiteturas simples.