 |
| Bellacosa Mainframe e a lasagna code rules |
☕ Um Café no Bellacosa Mainframe
Lasagna Code Rules sem Mistérios
Quando um Programador COBOL Descobriu que a Matrix Tinha Tantas Camadas que Nem o Arquiteto Sabia Mais Onde Estava o Problema
"Às vezes o problema não é falta de arquitetura. É arquitetura demais."
Prólogo — Quantas Matrix Existem Dentro da Matrix?
Neo finalmente conseguiu derrotar vários Agentes Smith.
A missão parecia simples.
Um cliente do banco não conseguia visualizar seu saldo.
Morpheus entregou a tarefa.
— Neo, descubra por que o saldo não aparece.
Neo sorriu.
— Deve ser um problema no programa COBOL.
Morpheus respondeu.
— Gostaria que fosse.
Neo iniciou a investigação.
Primeira camada.
Portal Web.
↓
Segunda camada.
API Gateway.
↓
Terceira camada.
Microserviço.
↓
Quarta camada.
Camada de Segurança.
↓
Quinta camada.
Camada de Auditoria.
↓
Sexta camada.
Camada de Observabilidade.
↓
Sétima camada.
Orquestrador.
↓
Oitava camada.
Middleware.
↓
Nona camada.
MQ.
↓
Décima camada.
z/OS Connect.
↓
Décima primeira camada.
CICS.
↓
Décima segunda camada.
Programa COBOL.
↓
Décima terceira camada.
COPYBOOK.
↓
Décima quarta camada.
Db2.
Neo respirou fundo.
Perguntou:
— O saldo está errado onde?
Morpheus respondeu.
— Ainda não sabemos.
Você só chegou na metade.
O Oráculo apareceu.
Sorriu.
— Bem-vindo ao Lasagna Code.
O que é Lasagna Code?
Lasagna Code (Código Lasanha) é um antipadrão onde um sistema possui tantas camadas de abstração, componentes intermediários e níveis de encapsulamento que compreender o fluxo completo torna-se extremamente difícil.
Enquanto o Spaghetti Code representa um fluxo caótico e desorganizado...
o Lasagna Code representa um fluxo extremamente organizado...
mas exageradamente profundo.
Cada camada parece correta.
O problema é que existem camadas demais.
A origem do termo
O termo começou a aparecer na década de 1990.
Ele surgiu como contraponto ao famoso Spaghetti Code.
A ideia era simples.
Se o espaguete é um emaranhado horizontal...
a lasanha cresce verticalmente.
Camada.
Sobre camada.
Sobre camada.
Até ninguém mais enxergar a base.
Matrix explica perfeitamente
Durante toda a trilogia descobrimos algo surpreendente.
Existe:
A Matrix.
Dentro dela existem programas.
Dentro dos programas existem agentes.
Dentro dos agentes existem regras.
Depois descobrimos:
O Arquiteto.
O Oráculo.
O Merovíngio.
O Chaveiro.
O Código Fonte.
Cada descoberta revela outra camada.
O software moderno também.
O nascimento da Lasanha
Curiosamente...
Lasagna Code nasce por boas intenções.
Alguém diz:
"Vamos separar responsabilidades."
Excelente ideia.
Depois.
"Vamos criar outra camada."
Boa ideia.
Depois.
"Mais uma para desacoplar."
Também boa.
Depois.
"Outra para facilitar manutenção."
Ainda parece correto.
Quando percebem...
existem quinze camadas para executar um único SELECT.
Um exemplo simples
Objetivo.
Consultar saldo.
Fluxo ideal.
Tela
↓
Programa COBOL
↓
Db2
Agora imagine uma arquitetura exagerada.
Tela
↓
Frontend
↓
BFF
↓
API Gateway
↓
REST
↓
Load Balancer
↓
Service Mesh
↓
Microserviço A
↓
Microserviço B
↓
Serviço de Autenticação
↓
Serviço de Logging
↓
Serviço de Auditoria
↓
MQ
↓
z/OS Connect
↓
CICS
↓
COBOL
↓
Db2
Todas as camadas possuem justificativa.
Mas será que todas são realmente necessárias?
O Programador COBOL Padawan
Imagine.
Você recebe um chamado.
"Corrigir o cálculo do limite."
Você abre o COBOL.
Nada errado.
Depois descobre.
O problema estava:
na serialização JSON.
Não.
Na verdade.
Na camada REST.
Também não.
Era um timeout do Gateway.
Horas depois.
Descobre.
Era uma configuração do Balanceador.
O efeito psicológico
Existe um comportamento curioso.
Arquitetos gostam de criar abstrações.
E abstrações realmente resolvem muitos problemas.
O perigo aparece quando começamos a abstrair...
a própria abstração.
Matrix Reloaded
Neo conversa com o Arquiteto.
O Arquiteto explica.
Existe:
uma Matrix.
Mas também:
uma Matrix para controlar a Matrix.
Depois mecanismos para controlar quem controla.
Arquitetura excessiva segue exatamente essa lógica.
O Arquiteto da Matrix
Imagine um Arquiteto de Software dizendo:
"Vamos criar uma camada para desacoplar outra camada que desacopla uma terceira camada responsável por abstrair a quarta camada."
Pode parecer sofisticado.
Mas talvez ninguém consiga manter isso daqui cinco anos.
Como reconhecer Lasagna Code?
Faça uma pergunta simples.
Quantas camadas um dado percorre?
Se uma consulta simples passa por quinze componentes...
talvez exista excesso.
O exemplo COBOL
Cliente consulta saldo.
Fluxo.
HTML
↓
JavaScript
↓
React
↓
REST
↓
OAuth
↓
Gateway
↓
NGINX
↓
MQ
↓
JSON
↓
CICS
↓
COBOL
↓
COPYBOOK
↓
SQL
↓
Db2
Cada etapa adiciona:
latência.
Complexidade.
Risco.
Logs.
Monitoramento.
Testes.
O Agente Smith adora Lasanha
Porque cada camada cria mais lugares para esconder bugs.
Agora um erro pode estar:
na API.
No Gateway.
No MQ.
No CICS.
No COBOL.
No Db2.
Ou simplesmente na conversão UTF-8.
Os sintomas
Muitas dependências
Tudo depende de tudo.
Debug difícil
Breakpoint atravessa quinze tecnologias.
Logs espalhados
Cada camada gera um log diferente.
Tempo de resposta aumenta
Cada salto possui custo.
Testes demorados
Mais componentes.
Mais cenários.
O Mainframe sofre?
Curiosamente.
Às vezes.
Hoje um programa COBOL pode conversar com:
REST.
JSON.
Kafka.
MQ.
Cloud.
Mobile.
IA.
Tudo isso é excelente.
Desde que exista necessidade.
Um exemplo inspirado na Matrix
Neo pergunta:
"Quem autorizou esta transação?"
Resposta.
"Precisamos consultar sete serviços."
Neo responde.
"Mas ontem eram dois."
Morpheus suspira.
"Ontem havia menos camadas."
Como nasce?
Primeiro.
Uma camada.
Depois.
Outra.
Depois.
Um Framework.
Depois.
Outro Framework.
Depois.
Outro Middleware.
Depois.
Outro Proxy.
Depois.
Outro Adaptador.
Cada um resolve um pequeno problema.
Todos juntos criam um problema maior.
Existe Lasagna boa?
Sim.
Toda arquitetura moderna possui camadas.
MVC.
Hexagonal.
Clean Architecture.
DDD.
Onion.
Todas utilizam camadas.
O segredo está no equilíbrio.
Camadas devem:
reduzir complexidade.
Nunca aumentá-la.
A diferença
Arquitetura saudável.
Cada camada possui responsabilidade clara.
Arquitetura Lasanha.
Cada camada apenas encaminha chamadas.
Sem agregar valor.
O custo invisível
Imagine.
Uma alteração simples.
Antes.
Um programa.
Hoje.
Treze repositórios.
Quatro equipes.
Cinco pipelines.
Duas aprovações.
O mesmo requisito.
O impacto financeiro
Cada camada possui:
infraestrutura.
monitoramento.
backup.
segurança.
deploy.
licenciamento.
Suporte.
Camadas custam dinheiro.
Atenção!
Nem toda arquitetura complexa é ruim.
Bancos precisam:
segurança.
auditoria.
resiliência.
alta disponibilidade.
Mas existe diferença entre:
complexidade necessária
e
complexidade acidental.
O papel do COBOL
COBOL costuma ficar exatamente na última camada.
Recebe dados.
Executa regras.
Grava Db2.
Ele normalmente não cria a lasanha.
Mas participa dela.
Ferramentas ajudam
Hoje podemos visualizar dependências utilizando:
IBM ADDI
Application Discovery
Dynatrace
Instana
OpenTelemetry
Jaeger
Zipkin
Elas mostram exatamente quantas camadas existem.
Os riscos
Latência
Cada camada adiciona milissegundos.
Custos
Mais servidores.
Debug
Muito mais difícil.
Segurança
Mais pontos de ataque.
Disponibilidade
Mais componentes.
Maior chance de falhas.
Curiosidade
Grandes empresas descobriram que alguns microsserviços estavam fazendo apenas:
Receber.
Chamar outro.
Retornar.
Sem nenhuma lógica.
Esses serviços foram eliminados.
A arquitetura ficou:
mais simples.
Mais rápida.
Mais barata.
O ensinamento do Oráculo
O Oráculo entrega uma lasanha para Neo.
Pergunta.
"O que você vê?"
Neo responde.
"Camadas."
Ela sorri.
"E se eu colocar cinquenta camadas?"
Neo pensa.
"Não conseguirei comer."
Ela responde.
"Nem manter."
Como evitar?
Cada camada precisa justificar sua existência
Remova abstrações inúteis
Faça diagramas
Meça latência
Revise arquitetura regularmente
Evite Framework por moda
Questione
"Esta camada agrega valor?"
Erros clássicos
Criar adaptadores desnecessários.
Framework para resolver problema inexistente.
Microserviços extremamente pequenos.
Excesso de interfaces.
Objetos que apenas chamam outros objetos.
Camadas vazias.
Aplicabilidade
Lasagna Code aparece em:
Java
.NET
COBOL
Cloud
Kubernetes
APIs
Microsserviços
Mobile
Sistemas Bancários
DevOps
Lições para um Programador COBOL Padawan
Ao ingressar em um ambiente corporativo, especialmente no universo IBM Z, você perceberá que sistemas modernos dificilmente são compostos apenas por COBOL e Db2. Eles convivem com APIs REST, gateways, filas MQ, microsserviços, autenticação federada, monitoramento distribuído e plataformas em nuvem.
Essas camadas são importantes quando resolvem problemas reais, como segurança, escalabilidade, desacoplamento ou auditoria. Entretanto, o bom engenheiro aprende a perguntar constantemente:
Esta camada tem uma responsabilidade clara?
Ela agrega valor ao negócio?
Poderia ser removida sem perda funcional?
Está simplificando ou apenas escondendo a complexidade?
Essa capacidade de questionar evita que arquiteturas elegantes no papel se tornem impossíveis de manter na prática.
Conclusão — Nem Toda Matrix Precisa de Outra Matrix
No final de Matrix Reloaded, Neo descobre que a realidade era muito mais profunda do que imaginava. Cada resposta revelava uma nova camada. Porém, diferente do filme, na Engenharia de Software nós podemos escolher quando criar uma nova camada — e quando parar.
Uma arquitetura em camadas é uma das maiores conquistas da engenharia moderna. Ela organiza responsabilidades, facilita testes e melhora a manutenção. Mas, quando utilizada sem critério, transforma-se em Lasagna Code, onde cada solicitação percorre um caminho tão longo que localizar um simples defeito torna-se uma expedição.
Para um Programador COBOL, essa lição é especialmente importante. O IBM Z continuará sendo o coração de muitos sistemas críticos, mas esse coração não precisa ficar escondido atrás de dezenas de camadas desnecessárias. Arquitetura existe para reduzir a complexidade percebida, não para multiplicá-la.
No universo Bellacosa Mainframe existe uma regra digna do Arquiteto da Matrix:
"Uma nova camada só merece existir quando elimina mais complexidade do que cria."
Se ela apenas empilha software sobre software, talvez você não esteja construindo uma arquitetura.
Talvez esteja apenas preparando uma lasanha tão alta que ninguém mais conseguirá encontrar o prato.
