Camadas arquiteturais | Livro Fundamentos de Arquitetura de Software | Arquitetura
- Camadas arquiteturais | Livro Fundamentos de Arquitetura de Software | Arquitetura
Arquitetura em camadas
Antipadrão sinkhole
No sinkhole anti-pattern é quando a requisição só “afunda” pelas camadas, passando de uma para outra como mero repasse, sem lógica relevante em cada nível. Isso gera trabalho desnecessário, mais objetos/processamento e pode piorar memória e performance.
Em poucas palavras: muitas camadas, pouco valor real em cada uma.
A avaliação que o livro sugere é basicamente esta:
- até
~20%das requisições serem só “pass-through” é aceitável - se
~80%das requisições virarem sinkhole, isso é um forte sinal de que a arquitetura em camadas não é a ideal para aquele domínio
Por que usar esse estilo?
- a aplicação é pequena e simples
- há orçamento e prazo muito apertados
- ele serve bem como ponto de partida
- o arquiteto ainda não tem certeza de qual estilo arquitetural será o melhor
Classificação da arquitetura
| Característica | Classificação |
|---|---|
| Partitioning type | Technical |
| Number of quanta | 1 |
| Deployability | 1 estrela |
| Elasticity | 1 estrela |
| Evolutionary | 1 estrela |
| Fault tolerance | 1 estrela |
| Modularity | 1 estrela |
| Overall cost | 5 estrelas |
| Performance | 2 estrelas |
| Reliability | 3 estrelas |
| Scalability | 1 estrela |
| Simplicity | 5 estrelas |
| Testability | 2 estrelas |
- 1 estrela: a característica não é bem suportada pela arquitetura
- 5 estrelas: a característica é um dos pontos mais fortes do estilo arquitetural
Arquitetura em pipeline
O que é
A pipeline architecture (ou pipes and filters) organiza o fluxo em uma sequência de etapas independentes.
Cada filtro faz uma única coisa e repassa o resultado pelo pipe para o próximo filtro.
Em poucas palavras: o dado entra, passa por etapas especializadas e sai transformado.
Por que usar esse estilo?
- o fluxo é simples e unidirecional
- cada etapa pode ser separada por responsabilidade
- é boa para transformação, validação e enriquecimento de dados
- funciona muito bem em processamento em sequência
Classificação da arquitetura
| Característica | Classificação |
|---|---|
| Partitioning type | Technical |
| Number of quanta | 1 |
| Deployability | 2 estrelas |
| Elasticity | 1 estrela |
| Evolutionary | 3 estrelas |
| Fault tolerance | 1 estrela |
| Modularity | 4 estrelas |
| Overall cost | 5 estrelas |
| Performance | 3 estrelas |
| Reliability | 3 estrelas |
| Scalability | 1 estrela |
| Simplicity | 5 estrelas |
| Testability | 2 estrelas |
- 1 estrela: a característica não é bem suportada pela arquitetura
- 5 estrelas: a característica é um dos pontos mais fortes do estilo arquitetural
Arquitetura microkernel
O que é
A microkernel architecture (ou plug-in architecture) divide a aplicação em um núcleo central e componentes plugáveis.
O núcleo fica com o essencial para o sistema funcionar, enquanto os plug-ins adicionam comportamentos, regras específicas, extensões e personalizações.
Em poucas palavras: um núcleo pequeno e estável, com funcionalidades crescendo por plug-ins.
Por que usar esse estilo?
- é um encaixe natural para aplicações baseadas em produto
- permite adicionar novas funcionalidades sem inflar o núcleo
- ajuda a isolar código mais volátil
- favorece extensibilidade, adaptabilidade e customizações
Classificação da arquitetura
| Característica | Classificação |
|---|---|
| Partitioning type | Core + plug-ins |
| Number of quanta | 1 |
| Deployability | 3 estrelas |
| Elasticity | 1 estrela |
| Evolutionary | 4 estrelas |
| Fault tolerance | 1 estrela |
| Modularity | 5 estrelas |
| Overall cost | 3 estrelas |
| Performance | 3 estrelas |
| Reliability | 3 estrelas |
| Scalability | 1 estrela |
| Simplicity | 3 estrelas |
| Testability | 4 estrelas |
- 1 estrela: a característica não é bem suportada pela arquitetura
- 5 estrelas: a característica é um dos pontos mais fortes do estilo arquitetural
Anotações
- Os plugins podem ter seu próprio banco de dados ou fonte de dados
- O sistema central precisa saber quais módulos de plugin estão disponíveis e usamos um registro de plugin para isso
- Tende a ser um arquivo que segue o padrão dizendo o que está disponível com as informações necessárias
Caso de uso
- Jenkins
- Chrome
- Jira
- Firefox
Abaixo está a continuação no mesmo estilo do seu markdown. Usei como base a estrutura dos capítulos do Fundamentals of Software Architecture, que lista os estilos restantes como Service-Based, Event-Driven, Space-Based, Orchestration-Driven Service-Oriented Architecture e Microservices . Também considerei o seu conteúdo já montado para manter padrão de escrita e tabela .
Arquitetura baseada em serviços
O que é
A service-based architecture organiza a aplicação em uma interface separada, serviços remotos e geralmente um banco de dados compartilhado.
Ela fica entre o monólito modular e microsserviços: a aplicação já é quebrada em serviços implantáveis separadamente, mas esses serviços costumam ser mais grossos, ou seja, com mais responsabilidade por domínio.
Em poucas palavras: quebra o sistema em serviços por domínio, mas sem exigir o nível extremo de independência dos microsserviços.
Por que usar esse estilo?
- é uma evolução natural de um monólito
- reduz o risco de ir direto para microsserviços
- permite separar partes do sistema sem quebrar o banco imediatamente
- melhora deploy, teste e manutenção em comparação com um monólito grande
- funciona bem quando os domínios são claros, mas ainda existe forte dependência de dados
Classificação da arquitetura
| Característica | Classificação |
|---|---|
| Partitioning type | Domain |
| Number of quanta | 1 to many |
| Deployability | 4 estrelas |
| Elasticity | 2 estrelas |
| Evolutionary | 3 estrelas |
| Fault tolerance | 4 estrelas |
| Modularity | 4 estrelas |
| Overall cost | 4 estrelas |
| Performance | 3 estrelas |
| Reliability | 4 estrelas |
| Scalability | 3 estrelas |
| Simplicity | 3 estrelas |
| Testability | 4 estrelas |
- 1 estrela: a característica não é bem suportada pela arquitetura
- 5 estrelas: a característica é um dos pontos mais fortes do estilo arquitetural
Anotações
- Normalmente possui de
4a12serviços. - Os serviços são mais coarse-grained, ou seja, maiores e mais voltados a domínio.
- Pode usar banco único compartilhado.
- Pode usar API Gateway, mas não é obrigatório.
- Costuma ser um excelente passo intermediário antes de microsserviços.
Caso de uso
- sistemas monolíticos grandes que precisam ser quebrados gradualmente
- sistemas corporativos com domínios claros
- aplicações que precisam melhorar deploy sem assumir toda a complexidade de microsserviços
- cenários onde quebrar o banco agora seria caro demais
Arquitetura orientada a eventos
O que é
A event-driven architecture organiza o sistema em produtores, consumidores e eventos.
Em vez de um componente chamar outro diretamente, ele publica um evento, e outros componentes reagem a esse evento de forma assíncrona.
Em poucas palavras: o sistema reage a acontecimentos, em vez de depender apenas de chamadas diretas.
Por que usar esse estilo?
- alta escalabilidade
- alta performance em fluxos assíncronos
- desacoplamento entre produtores e consumidores
- boa resposta para cenários dinâmicos
- favorece processamento paralelo
- funciona bem quando não é necessário responder tudo imediatamente
Classificação da arquitetura
| Característica | Classificação |
|---|---|
| Partitioning type | Technical |
| Number of quanta | 1 to many |
| Deployability | 3 estrelas |
| Elasticity | 3 estrelas |
| Evolutionary | 5 estrelas |
| Fault tolerance | 5 estrelas |
| Modularity | 4 estrelas |
| Overall cost | 3 estrelas |
| Performance | 5 estrelas |
| Reliability | 3 estrelas |
| Scalability | 5 estrelas |
| Simplicity | 1 estrela |
| Testability | 2 estrelas |
- 1 estrela: a característica não é bem suportada pela arquitetura
- 5 estrelas: a característica é um dos pontos mais fortes do estilo arquitetural
Anotações
- Pode usar broker topology, com mensagens publicadas em filas, tópicos ou streams.
- Pode usar mediator topology, com um componente central orquestrando o fluxo.
- Normalmente trabalha com consistência eventual.
- É mais difícil de testar e debugar, porque o fluxo pode ser não determinístico.
- Ajuda a remover gargalos e criar pontos de back pressure.
Caso de uso
- sistemas de pagamento
- processamento de pedidos
- integrações assíncronas
- notificações
- processamento de eventos de IoT
- sistemas com alto volume de mensagens
- pipelines de dados
- arquiteturas com RabbitMQ, Kafka, NATS, Azure Service Bus ou AWS SNS/SQS
Arquitetura space-based
O que é
A space-based architecture é voltada para aplicações com altíssimo volume de carga concorrente.
A ideia central é remover o banco de dados como gargalo direto da requisição, usando processamento em memória, cache distribuído, data grid e unidades de processamento replicadas.
Em poucas palavras: processa em memória primeiro e sincroniza com o banco depois.
Por que usar esse estilo?
- precisa lidar com picos extremos de acesso
- o banco de dados virou gargalo
- a aplicação precisa de elasticidade alta
- a carga é muito variável
- é necessário escalar horizontalmente com agressividade
- o sistema precisa suportar muitos usuários simultâneos
Classificação da arquitetura
| Característica | Classificação |
|---|---|
| Partitioning type | Domain and technical |
| Number of quanta | 1 to many |
| Deployability | 3 estrelas |
| Elasticity | 5 estrelas |
| Evolutionary | 3 estrelas |
| Fault tolerance | 3 estrelas |
| Modularity | 3 estrelas |
| Overall cost | 2 estrelas |
| Performance | 5 estrelas |
| Reliability | 4 estrelas |
| Scalability | 5 estrelas |
| Simplicity | 1 estrela |
| Testability | 1 estrela |
- 1 estrela: a característica não é bem suportada pela arquitetura
- 5 estrelas: a característica é um dos pontos mais fortes do estilo arquitetural
Anotações
- Usa processing units para processar as requisições.
- Usa virtualized middleware para abstrair comunicação, dados e processamento.
- Usa data grid para manter dados em memória.
- Usa data pumps para sincronizar dados com o banco.
- Reduz pressão direta sobre o banco.
- É poderosa, mas complexa e cara.
Caso de uso
- venda de ingressos com picos massivos
- leilões online
- Black Friday
- sistemas de reserva
- sistemas financeiros com altíssima concorrência
- aplicações onde o banco é o principal gargalo de escala
Arquitetura orientada a serviços com orquestração
O que é
A orchestration-driven service-oriented architecture é uma arquitetura baseada em serviços com um motor central de orquestração.
Esse motor coordena o fluxo entre serviços de negócio, serviços de aplicação, serviços corporativos e serviços de infraestrutura.
Em poucas palavras: um orquestrador central decide e coordena o fluxo entre serviços.
Por que usar esse estilo?
- há muitos sistemas corporativos legados
- é necessário reutilizar serviços existentes
- existe uma organização com forte governança centralizada
- os fluxos de negócio precisam ser coordenados por um motor central
- há integração pesada entre sistemas heterogêneos
Classificação da arquitetura
| Característica | Classificação |
|---|---|
| Partitioning type | Technical |
| Number of quanta | 1 |
| Deployability | 1 estrela |
| Elasticity | 3 estrelas |
| Evolutionary | 1 estrela |
| Fault tolerance | 3 estrelas |
| Modularity | 3 estrelas |
| Overall cost | 1 estrela |
| Performance | 2 estrelas |
| Reliability | 2 estrelas |
| Scalability | 4 estrelas |
| Simplicity | 1 estrela |
| Testability | 1 estrela |
- 1 estrela: a característica não é bem suportada pela arquitetura
- 5 estrelas: a característica é um dos pontos mais fortes do estilo arquitetural
Anotações
- É muito associada ao SOA clássico.
- Costuma usar ESB ou algum motor de orquestração.
- Favorece reutilização, mas aumenta acoplamento.
- O orquestrador pode virar um ponto central de dependência.
- Pode juntar problemas de arquitetura monolítica com problemas de arquitetura distribuída.
Caso de uso
- grandes empresas com sistemas legados
- integração entre ERPs, CRMs, sistemas fiscais e sistemas internos
- ambientes com governança central forte
- cenários onde o fluxo precisa ser controlado por uma camada central
Arquitetura de microsserviços
O que é
A microservices architecture divide o sistema em serviços pequenos, independentes, implantáveis separadamente e alinhados a capacidades de negócio.
Cada microsserviço deve ter alta coesão, baixo acoplamento e, idealmente, possuir seus próprios dados.
Em poucas palavras: serviços pequenos, independentes e organizados por domínio de negócio.
Por que usar esse estilo?
- times precisam trabalhar de forma independente
- cada parte do sistema precisa escalar de forma diferente
- o negócio muda com frequência
- é necessário deploy independente por serviço
- domínios são bem definidos
- há maturidade operacional para lidar com observabilidade, CI/CD, containers, rede, contratos e falhas distribuídas
Classificação da arquitetura
| Característica | Classificação |
|---|---|
| Partitioning type | Domain |
| Number of quanta | 1 to many |
| Deployability | 4 estrelas |
| Elasticity | 5 estrelas |
| Evolutionary | 5 estrelas |
| Fault tolerance | 4 estrelas |
| Modularity | 5 estrelas |
| Overall cost | 1 estrela |
| Performance | 2 estrelas |
| Reliability | 4 estrelas |
| Scalability | 5 estrelas |
| Simplicity | 1 estrela |
| Testability | 4 estrelas |
- 1 estrela: a característica não é bem suportada pela arquitetura
- 5 estrelas: a característica é um dos pontos mais fortes do estilo arquitetural
Anotações
- Cada serviço deve representar um bounded context ou uma capacidade de negócio.
- Cada serviço deve ser implantável de forma independente.
- Cada serviço deve tentar controlar seus próprios dados.
- Comunicação pode ser síncrona, assíncrona ou híbrida.
- Exige automação forte de deploy, observabilidade, versionamento de contratos e resiliência.
- Pode usar API Gateway, service mesh, sidecars, eventos e sagas.
Caso de uso
- plataformas grandes
- produtos com múltiplos times
- sistemas com domínios bem separados
- sistemas que precisam escalar partes específicas
- empresas com maturidade DevOps
- aplicações onde deploy independente é uma necessidade real
Diferença entre service-based architecture e microservices
Essa é a parte mais importante.
A service-based architecture não é simplesmente “microsserviços com outro nome”. Ela é um estilo híbrido: possui serviços separados, mas normalmente mantém serviços maiores e banco compartilhado. Já microsserviços empurram a independência muito mais longe: serviços menores, ownership de dados, deploy independente, isolamento operacional e menor acoplamento. O livro Software Architecture: The Hard Parts reforça essa distinção ao descrever service-based como uma estrutura distribuída macro-layered com UI separada, serviços remotos coarse-grained e banco monolítico, enquanto microsserviços buscam maior isolamento, especialmente no nível de dados .
| Ponto | Service-based architecture | Microservices architecture |
|---|---|---|
| Granularidade | Serviços maiores | Serviços menores |
| Particionamento | Por domínio | Por domínio |
| Banco de dados | Geralmente compartilhado | Preferencialmente banco por serviço |
| Transação | Mais fácil usar ACID | Frequentemente usa sagas e consistência eventual |
| Deploy | Serviço pode ser implantado separadamente | Cada serviço deve ser implantável separadamente |
| Complexidade operacional | Menor | Maior |
| Custo | Menor | Maior |
| Simplicidade | Mais simples | Mais complexo |
| Escalabilidade | Boa, mas menos precisa | Muito alta e mais granular |
| Elasticidade | Média | Alta |
| Acoplamento | Menor que monólito, maior que microservices | Baixo, se bem feito |
| Quantidade comum de serviços | Poucos serviços, geralmente 4 a 12 | Muitos serviços, dependendo do domínio |
| Banco compartilhado | Aceitável e comum | Geralmente evitado |
| Melhor uso | Modernização gradual | Alta independência, escala e evolução |
Exemplo prático
Service-based
Sistema de vendas
├── PedidoService
├── PagamentoService
├── EstoqueService
├── ClienteService
└── Banco de dados compartilhado
Aqui cada serviço é separado, mas todos podem acessar o mesmo banco.
Microservices
Sistema de vendas
├── PedidoService
│ └── PedidoDb
├── PagamentoService
│ └── PagamentoDb
├── EstoqueService
│ └── EstoqueDb
├── ClienteService
│ └── ClienteDb
└── Comunicação via API/eventos
Aqui cada serviço possui sua própria base ou ao menos seu próprio modelo de persistência.
Diferença em uma frase
Service-based architecture separa a aplicação em serviços, mas ainda aceita acoplamentos estruturais como banco compartilhado. Microsserviços tentam levar a independência ao limite: serviço, deploy, dados, operação e evolução separados.
Quando escolher service-based
- você está saindo de um monólito
- quer reduzir risco
- ainda não consegue quebrar o banco
- a equipe não tem maturidade operacional para microsserviços
- a aplicação precisa melhorar modularidade e deploy, mas sem virar uma plataforma distribuída complexa
Quando escolher microsserviços
- cada domínio precisa escalar de forma independente
- times precisam fazer deploy sem depender uns dos outros
- há maturidade em CI/CD, observabilidade e infraestrutura
- o sistema suporta bem consistência eventual
- a organização consegue lidar com contratos, versionamento e falhas distribuídas
Ponto de atenção
Ir direto para microsserviços sem maturidade costuma trocar um monólito simples por um sistema distribuído difícil de operar.
Por isso, a service-based architecture pode ser usada como um degrau intermediário entre monólito e microsserviços. O Software Architecture: The Hard Parts também trata service-based como um bom stepping-stone para microsserviços, porque permite decompor por domínio antes de atacar a separação física do banco de dados .