Executando verificação de segurança...
Respondendo a "Não sei se foi os ramos que trabalhei (primeiro..." dentro da publicação Em projetos reais, em que momento os diagramas de banco de dados deixam de representar a realidade?
1
taguitos2106

Concordo contigo que, em ambientes mais regulados (fiscal, contábil, trabalhista), a documentação precisa vir antes e ser aprovada, porque a própria natureza do negócio não permite improviso. Nesses cenários, o projeto técnico realmente é a fonte da verdade.

O ponto que tenho observado com mais frequência é fora desses ambientes: produtos digitais, SaaS, startups e até times médios, onde a pressão por entrega contínua e mudança rápida acaba quebrando esse modelo ideal. Não por discordância conceitual. quase todo mundo concorda que documentar é essencial — mas porque, na prática, a manutenção manual não escala bem quando as mudanças são constantes.

Por isso vejo cada vez mais valor em reduzir ao máximo a dependência exclusiva do fator humano. Quando diagramas e documentação conseguem ser derivados automaticamente daquilo que foi implementado, ou pelo menos sincronizados com a execução real, o risco de divergência cai muito. A documentação continua sendo parte do trabalho, mas deixa de ser um gargalo ou um ponto frágil do processo.

No fim, acho que estamos falando do mesmo objetivo: evitar dívida técnica e perda de controle. A diferença é o caminho. Em contextos ideais e bem estruturados, o projeto continua sendo a fonte da verdade. Em contextos mais dinâmicos, a automação vira uma aliada para garantir que essa verdade não se perca ao longo do tempo.

Carregando publicação patrocinada...
3
RomeuGomesDev

existem diversas ferramentas de WorkBench para "gerar" o código, a estratégia de CI/CD a partir de mudanças no Diagrama, se estiver-mos usando as ferramentas corretas de modo correto, uma atualização de diagrama já "cospe" o pipeline que será necessário no CI/CD e o novo diagrama, mostra para os Devs o que fazer, e como fazer.
Startups hoje, em suma maioria, usam a estratégia de fatiar pão francês com motosserras, ou seja, partem para uma solução que aparenta ser viável e escalável, e barata. No caso, quando tiverem milhares de usuários a faca terá que ser mecanizada e automática para fatiar muito mais pães sem precisar de pessoas, porém uma maquina industrial de fatiar pães custa muito caro, e uma motosserra que consegue cortar arvores também deve servir.
SaaS existem alguns muito bons, hoje virou roupa, todo mundo tem e quer usar da maneira que se sente melhor, alguns tem qualidade, outros tem preço, outros tem disponibilidade.... na pior situação dessas 3 opções você fica com 2.
Infelizmente, o modelo de negócios de alguns projetos acaba priorizando a divida técnica. A filosofia ágil foi distorcida para se tornar sinônimo de sem documentação ou que a entrega é a prioridade, o resto fica pra depois.
O ágil, realmente, é ter o controle de cada pequena ação cada pequeno sprint, e ser tão SIMPLES que no final do SPRINT ele já esta AUTODOCUMENTADO a filosofia, deveria seguir o principio de que ao colocar a mão na massa e fazer, o projeto já foi definido ANTES. Ou seja, é o ponto CENTRAL não o gargalo.
Em times menores, esse cenário deveria ser ainda mais importante, tudo o que foi planejado antes deveria estar em execução, a dinamicidade, vem mascarando a falta de conhecimento, ou a vontade de empurrar com a barriga disfarçado de velocidade.
Desculpe, bato muito nesse contexto, pois a cada dia, o mercado DEV vem perdendo qualidade, o ego de muitos gerentes de projeto, acaba destruindo o mercado. Quando mudamos a prioridade, mais cedo ou mais tarde, temos a cobrança da dívida.

1
taguitos2106
  • Autor
    Autor

Acho que a gente concorda em mais pontos do que parece — principalmente no objetivo final: controle, previsibilidade e redução de dívida técnica.
Onde vejo a divergência não é no valor da documentação nem no modelo ideal, mas na aderência desse modelo ao contexto mais comum hoje, especialmente fora de ambientes altamente regulados.
Em setores como fiscal, contábil e trabalhista, o projeto técnico precisa ser a fonte da verdade. Aí não existe espaço para improviso. Já em produtos digitais, SaaS e startups, o que observo com mais frequência é um cenário onde:
o domínio muda rápido
hipóteses são testadas em produção
decisões de schema acontecem em ciclos curtos
nem sempre há um “engenheiro de software” dedicado apenas ao projeto e documentação
Nesse contexto, o problema não é falta de consciência — é escala. Manter diagramas e documentação manualmente sincronizados com dezenas de migrations semanais simplesmente não se sustenta bem.
Por isso minha provocação não é “documentar menos”, e sim reduzir o quanto a documentação depende exclusivamente de disciplina humana. Quando o diagrama passa a ser:
derivado do schema real
versionado junto com migrations
integrado ao pipeline
tratado como artefato vivo do código
ele deixa de competir com a entrega e passa a fazer parte dela.
No fim, vejo dois caminhos convergindo para o mesmo ponto:
em ambientes maduros e regulados, o projeto segue sendo a fonte da verdade
em ambientes altamente dinâmicos, a automação ajuda a preservar essa verdade ao longo do tempo
Talvez o erro do mercado não seja abandonar o projeto, mas insistir em modelos manuais onde a realidade já exige algo mais integrado e automático.