Quantum arquitetural, Quanta | Camadas arquiteturais | Livro Fundamentos de Arquitetura de Software | Arquitetura
- Quantum arquitetural, Quanta | Camadas arquiteturais | Livro Fundamentos de Arquitetura de Software | Arquitetura
No livro Fundamentos da Arquitetura de Software, os autores usam o termo architecture quantum, ou quantum arquitetural, para definir uma unidade arquitetural que pode ser analisada como uma parte coerente do sistema.
A definição apresentada no livro é:
Um architecture quantum é um artefato implantável de forma independente, com alta coesão funcional e connascence síncrona.
Em português direto:
Quantum arquitetural é a menor unidade da arquitetura que consegue funcionar, ser implantada e ser analisada como uma parte independente do sistema.
O plural de quantum é quanta.
Ideia principal
O conceito serve para responder uma pergunta arquitetural importante:
Essa parte do sistema pode ser tratada como uma unidade independente?
Ou seja:
Ela pode ser implantada sozinha?
Ela tem uma responsabilidade funcional clara?
Ela depende fortemente de outras partes em chamadas síncronas?
Ela possui banco, mensageria ou infraestrutura própria para funcionar?
Se a resposta for sim, provavelmente estamos olhando para um quantum arquitetural.
Por que esse conceito existe?
Em sistemas simples, normalmente avaliamos a arquitetura como um todo.
Exemplo:
Sistema inteiro precisa ser escalável.
Sistema inteiro precisa ser seguro.
Sistema inteiro precisa ser disponível.
Mas em sistemas maiores isso começa a ficar impreciso.
Nem toda parte do sistema precisa da mesma característica arquitetural.
Exemplo:
| Parte do sistema | Característica mais importante |
|---|---|
| Login | Segurança |
| Checkout | Consistência e confiabilidade |
| Catálogo | Performance e cache |
| Relatórios | Processamento assíncrono |
| Leilão ao vivo | Baixa latência e disponibilidade |
O livro mostra que o conceito de architecture quantum ajuda a analisar características arquiteturais em um escopo menor, e não apenas no sistema inteiro.
Os 3 critérios de um quantum arquitetural
1. Implantável de forma independente
Um quantum precisa conter tudo que ele precisa para funcionar.
Exemplo:
Serviço de Pedido
Banco de Pedido
Fila de Eventos de Pedido
Configurações necessárias
Isso significa que o banco de dados também pode fazer parte do quantum.
O livro deixa claro que, se uma aplicação depende de um banco para funcionar, esse banco faz parte do quantum. Por isso, sistemas legados com banco único normalmente formam um único quantum arquitetural.
Exemplo:
Monólito
├── UI
├── Backend
└── Banco único
Resultado: 1 quantum arquitetural
Mesmo que o código tenha vários módulos internos, se tudo depende do mesmo banco e é implantado junto, arquiteturalmente isso tende a ser um quantum só.
2. Alta coesão funcional
O quantum precisa ter uma responsabilidade clara.
Exemplo bom:
Quantum de Pagamento
Responsabilidade: processar pagamentos
Exemplo ruim:
Quantum Utilitário
Responsabilidade: coisas genéricas, helpers, funções aleatórias
O livro explica que alta coesão funcional significa que o quantum faz algo com propósito. Em microserviços, isso costuma se alinhar com um workflow ou com um bounded context do DDD.
Exemplo:
Pedido
Pagamento
Estoque
Entrega
Nota Fiscal
Cada um desses pode ser um quantum diferente, desde que tenha autonomia arquitetural suficiente.
3. Connascence síncrona
Aqui está a parte mais importante.
Connascence significa que duas partes estão acopladas de tal forma que uma mudança em uma pode exigir mudança na outra para manter o sistema correto.
No contexto de quantum arquitetural, o livro diferencia chamadas síncronas e assíncronas.
Uma chamada síncrona é assim:
Serviço A chama Serviço B
Serviço A fica esperando Serviço B responder
Exemplo:
Pedido -> Pagamento
Se o serviço de Pedido precisa esperar o Pagamento responder para continuar, os dois ficam ligados durante aquela operação.
O livro explica que, se um serviço chama outro de forma síncrona, eles não podem ter características operacionais muito diferentes. Se o chamador escala muito mais que o chamado, podem ocorrer timeouts e problemas de confiabilidade.
Exemplo problemático:
Serviço de Leilão suporta 10.000 req/s
Serviço de Pagamento suporta 50 req/s
Comunicação síncrona entre eles
Resultado provável:
Timeout
Fila interna crescendo
Falhas em cascata
Indisponibilidade parcial
Nesse caso, talvez eles estejam mais acoplados do que parecem.
Exemplo de monólito
Aplicação Web
├── Camada de apresentação
├── Camada de negócio
├── Camada de persistência
└── Banco de dados único
Mesmo com camadas bem organizadas, normalmente isso é:
1 quantum arquitetural
Porque:
Deploy é único
Banco é único
Escalabilidade é conjunta
Mudança tende a afetar o sistema inteiro
Características arquiteturais são compartilhadas
Exemplo de arquitetura baseada em serviços
Frontend
├── Serviço de Pedido
├── Serviço de Cliente
├── Serviço de Produto
└── Banco relacional único
Mesmo tendo vários serviços, se todos usam o mesmo banco, ainda pode ser:
1 quantum arquitetural
O livro Software Architecture: The Hard Parts reforça essa ideia: uma arquitetura service-based pode ter serviços separados, mas, se todos dependem de um banco monolítico compartilhado, o quantum arquitetural continua sendo único.
Exemplo de microserviços
Serviço de Pedido
└── Banco de Pedido
Serviço de Pagamento
└── Banco de Pagamento
Serviço de Estoque
└── Banco de Estoque
Aqui temos potencialmente:
3 quanta arquiteturais
Porque cada serviço:
tem responsabilidade própria
tem banco próprio
pode ser implantado separadamente
pode escalar separadamente
pode ter características arquiteturais diferentes
O livro comenta que, em microserviços, cada serviço pode formar seu próprio quantum, principalmente quando possui seu próprio banco e está alinhado a um bounded context.
Exemplo prático
Imagine um sistema de e-commerce:
Catálogo
Carrinho
Pedido
Pagamento
Entrega
Relatório
Nem tudo precisa ter as mesmas características.
| Quantum | Características principais |
|---|---|
| Catálogo | Leitura rápida, cache, alta escala |
| Carrinho | Baixa latência, estado temporário |
| Pedido | Consistência, confiabilidade |
| Pagamento | Segurança, rastreabilidade, auditoria |
| Entrega | Integração externa, resiliência |
| Relatório | Processamento assíncrono, tolerância a atraso |
Se tudo estiver no mesmo monólito com um banco único, você tem pouca liberdade para otimizar cada parte separadamente.
Se cada parte estiver em quanta separados, você consegue tomar decisões específicas por contexto.
Relação com características arquiteturais
Características arquiteturais são coisas como:
Escalabilidade
Performance
Disponibilidade
Segurança
Elasticidade
Resiliência
Manutenibilidade
Observabilidade
Confiabilidade
Sem o conceito de quantum, é comum dizer:
O sistema precisa ser escalável.
Mas isso é muito genérico.
Com quantum arquitetural, a análise fica melhor:
O quantum de Catálogo precisa ser altamente escalável.
O quantum de Pagamento precisa ser altamente seguro.
O quantum de Pedido precisa ser altamente confiável.
O quantum de Relatório aceita consistência eventual.
Essa é a utilidade do conceito: avaliar características arquiteturais no escopo correto.
Relação com banco de dados
Banco de dados é um dos pontos mais importantes.
Se vários serviços compartilham o mesmo banco:
Serviço A
Serviço B
Serviço C
↓
Banco único
Então eles estão acoplados por dados.
Mesmo que cada serviço tenha deploy separado, o banco cria dependência estrutural.
Isso reduz a independência dos serviços e pode transformar tudo em um único quantum.
Por isso, em microserviços mais puros, o comum é:
Serviço A -> Banco A
Serviço B -> Banco B
Serviço C -> Banco C
Isso aumenta a independência, mas também aumenta a complexidade.
Trade-off:
| Decisão | Vantagem | Custo |
|---|---|---|
| Banco único | Simplicidade, joins fáceis, consistência centralizada | Alto acoplamento |
| Banco por serviço | Independência, deploy separado, escala granular | Consistência distribuída, duplicação, eventos |
Relação com comunicação síncrona
Comunicação síncrona pode juntar quanta que pareciam separados.
Exemplo:
Pedido -> Pagamento -> Antifraude -> Banco
Se tudo depende de resposta imediata, o fluxo inteiro compartilha características operacionais.
Se o Antifraude cair, o Pedido também sofre.
Nesse caso, a arquitetura pode ter acoplamento operacional forte.
Alternativa:
Pedido publica evento PedidoCriado
Pagamento consome evento
Antifraude consome evento
Com comunicação assíncrona, cada parte pode ter mais independência.
O livro cita que comunicação assíncrona permite que serviços tenham características operacionais diferentes, porque o chamador não precisa ficar esperando a resposta direta do chamado.
Como identificar quanta em um sistema
Use estas perguntas:
| Pergunta | O que indica |
|---|---|
| Essa parte pode ser implantada sozinha? | Independência de deploy |
| Ela tem banco próprio? | Independência de dados |
| Ela representa um fluxo de negócio claro? | Coesão funcional |
| Ela depende de outro serviço síncrono para funcionar? | Acoplamento operacional |
| Ela pode escalar separadamente? | Independência operacional |
| Ela pode falhar sem derrubar o resto? | Isolamento |
| Ela tem características arquiteturais próprias? | Escopo arquitetural próprio |
Se a resposta for sim para a maioria, provavelmente você encontrou um quantum.
Sinais de que você tem apenas um quantum
Deploy sempre do sistema inteiro
Banco único compartilhado
Frontend fortemente acoplado ao backend inteiro
Serviços precisam subir juntos
Mudança em uma parte exige deploy em várias outras
Escala só é possível replicando tudo
Falha em uma parte derruba o fluxo inteiro
Chamadas síncronas em cadeia
Isso não é necessariamente errado.
Só significa que a arquitetura tem menor granularidade arquitetural.
Sinais de que você tem múltiplos quanta
Deploy independente
Banco por contexto
Responsabilidade funcional clara
Baixo acoplamento síncrono
Comunicação assíncrona quando apropriado
Escala separada
Times conseguem evoluir partes diferentes
Características arquiteturais diferentes por parte do sistema
Isso indica maior modularidade operacional.
Quantum arquitetural não é a mesma coisa que microserviço
Um microserviço pode ser um quantum, mas nem sempre é.
Exemplo:
Microserviço A
Microserviço B
Microserviço C
Banco único
Apesar de existirem três serviços, arquiteturalmente pode existir apenas:
1 quantum
Porque o banco único cria acoplamento.
Outro exemplo:
Serviço de Pedido
Serviço de Pagamento
Chamada síncrona obrigatória entre eles
Mesmo ciclo de deploy
Mesma base de dados
Nesse caso, talvez eles sejam serviços separados tecnicamente, mas não são quanta realmente independentes.
Quantum arquitetural também não é a mesma coisa que módulo
Um módulo é uma separação interna de código.
Exemplo:
Projeto .NET
├── Modulo.Clientes
├── Modulo.Pedidos
├── Modulo.Produtos
└── Modulo.Faturamento
Isso pode ser um monólito modular.
Mas se tudo é implantado junto e usa o mesmo banco, provavelmente continua sendo:
1 quantum arquitetural
Módulo é uma separação de código.
Quantum é uma separação arquitetural, operacional e funcional.
Exemplo em .NET
Um monólito modular em .NET:
MinhaAplicacao.Api
MinhaAplicacao.Clientes
MinhaAplicacao.Pedidos
MinhaAplicacao.Produtos
MinhaAplicacao.Faturamento
MinhaAplicacao.Infrastructure
Banco único
Mesmo separado em projetos, normalmente é:
1 quantum arquitetural
Agora uma versão distribuída:
Clientes.Api
Clientes.Database
Pedidos.Api
Pedidos.Database
Pagamentos.Api
Pagamentos.Database
Aqui pode existir:
3 quanta arquiteturais
Mas apenas se cada um tiver autonomia suficiente.
Onde esse conceito ajuda em decisões reais
1. Decidir se deve separar um serviço
Pergunta:
Esse componente tem motivo diferente para escalar, mudar ou ser protegido?
Se sim, talvez ele mereça ser outro quantum.
Exemplo:
Relatórios consomem muito processamento.
Checkout precisa de baixa latência.
Misturar os dois no mesmo quantum pode prejudicar ambos.
2. Decidir se banco deve ser compartilhado
Pergunta:
Compartilhar esse banco vai impedir deploy independente?
Se sim, o banco compartilhado está unindo os serviços em um mesmo quantum.
3. Decidir se comunicação deve ser síncrona ou assíncrona
Pergunta:
O serviço chamador precisa mesmo esperar a resposta agora?
Se não precisa, comunicação assíncrona pode reduzir o acoplamento entre quanta.
4. Definir características arquiteturais por contexto
Em vez de dizer:
O sistema precisa ser escalável.
Diga:
O quantum de comandos precisa suportar 6 mil conexões simultâneas.
O quantum de retorno precisa processar respostas de forma assíncrona.
O quantum administrativo pode ter menor escala.
Isso deixa a arquitetura mais precisa.
Aplicando ao seu contexto de comandos
Pensando em uma arquitetura de envio de comandos para clientes desktop:
API de orquestração de comandos
Hub SignalR
Redis backplane
Processador de retorno
Banco de rastreamento
Gateway/API externa
Você pode analisar os quanta assim:
| Parte | Pode ser quantum? | Motivo |
|---|---|---|
| Orquestração de comandos | Sim | Tem necessidade forte de conexão, roteamento e baixa latência |
| Processador de retorno | Sim | Tem outro ritmo, pode ser assíncrono e escalado diferente |
| Painel administrativo | Sim ou não | Depende se tem deploy e dados separados |
| Banco compartilhado | Pode unir quanta | Se todos dependem dele diretamente |
| Redis backplane | Faz parte do quantum operacional do SignalR | Sem ele, multi-instância pode não funcionar corretamente |
Exemplo:
Quantum 1: Comunicação em tempo real
├── API SignalR
├── Redis backplane
└── Estado necessário de conexão/grupos
Quantum 2: Processamento de retorno
├── API de retorno
├── Fila/canal interno
└── Persistência de resultado
Quantum 3: Administração
├── API administrativa
└── UI administrativa
Se todos compartilham o mesmo banco e dependem dele para funcionar, talvez a arquitetura ainda tenha um acoplamento forte.
Resumo rápido
| Conceito | Explicação |
|---|---|
| Quantum | Unidade arquitetural independente |
| Quanta | Plural de quantum |
| Critério 1 | Deploy independente |
| Critério 2 | Alta coesão funcional |
| Critério 3 | Connascence síncrona |
| Monólito | Normalmente 1 quantum |
| Monólito modular | Normalmente 1 quantum |
| Service-based com banco único | Muitas vezes 1 quantum |
| Microserviços com banco próprio | Pode ter múltiplos quanta |
| Comunicação síncrona forte | Pode unir quanta |
| Comunicação assíncrona | Pode reduzir acoplamento entre quanta |
Frase para memorizar
Quantum arquitetural é uma unidade funcional e operacional da arquitetura que pode ser implantada, analisada, escalada e evoluída com relativa independência.
Frase mais prática
Se uma parte do sistema tem motivo próprio para escalar, mudar, falhar, proteger ou ser implantada, talvez ela deva ser analisada como um quantum arquitetural separado.