O que sobra de um software quando ninguém mais mantém ele?

Grande parte das discussões sobre arquitetura de software gira em torno de mudança:
como evoluir mais rápido, como refatorar com segurança, como trocar tecnologia sem dor.

Mas existe uma pergunta que quase nunca aparece:

O que acontece quando a mudança para?

Na prática, muitos sistemas de longa duração não morrem por problemas de performance ou escalabilidade. Eles morrem porque, com o tempo, perdem coerência conceitual.
Regras de negócio vazam para a infraestrutura, decisões arquiteturais se tornam irreversíveis, e o sistema acaba sendo reescrito não porque está “errado”, mas porque ninguém mais consegue entendê-lo.

Recentemente encontrei um paper técnico que propõe uma forma diferente de pensar arquitetura, tratando o tempo como uma restrição arquitetural primária, e não como um detalhe implícito.

Legacy-First Design (LFD)

O método apresentado no paper se chama Legacy-First Design (LFD).

Ele não é um framework, nem um novo padrão arquitetural.
O foco está no nível de decisão arquitetural, partindo de uma distinção explícita entre:

o que precisa durar

e o que pode mudar ao longo do tempo

Em vez de otimizar apenas para velocidade de entrega ou conveniência tecnológica, o LFD prioriza:

• preservação da identidade do sistema
• independência tecnológica do núcleo
• clareza conceitual ao longo dos anos
• sobrevivência mesmo sem manutenção ativa

A pergunta central deixa de ser:

“Como estruturar o sistema para mudar mais rápido?”

e passa a ser:

“O que precisa continuar fazendo sentido mesmo quando ninguém mais mexer no código?”

“Survival in Abandoned State”

Um dos conceitos mais interessantes do paper é o de Survival in Abandoned State.

A maioria das arquiteturas assume, implicitamente, que sempre haverá manutenção contínua.
O LFD não assume isso.

Ele trata o abandono como um estado previsível no ciclo de vida do software.
Sob essa ótica, um sistema que colapsa conceitualmente quando é abandonado falhou arquiteturalmente, mesmo que tenha funcionado bem no passado.

Projetar pensando nisso significa criar sistemas que:

• ainda podem ser compreendidos sem os autores originais
• preservam o significado central do domínio
• não dependem de conhecimento tribal para “não quebrar”

Relação com práticas conhecidas

O paper deixa claro que o LFD não substitui abordagens como Clean Architecture, DDD ou Arquitetura Hexagonal.

Ele funciona como uma camada de governança temporal, orientando onde essas práticas devem ser aplicadas e o que precisa ser protegido da mudança.

Leitura complementar

O paper é curto, conceitual e direto ao ponto:

📄 Legacy-First Design (LFD): A Temporal Approach to Software Sustainability
👉 https://zenodo.org/records/18208444

Vale a leitura, principalmente para quem trabalha com:

• sistemas legados
• plataformas que precisam durar anos
• código que troca de time com frequência

Para debate

Queria jogar a pergunta pra discussão:

👉 Vocês já trabalharam em sistemas que “funcionavam”, mas ninguém mais conseguia entender?
👉 O que, na prática, ajudou (ou atrapalhou) a sobrevivência desses sistemas ao longo do tempo?

Curioso pra ouvir experiências reais.