Estudo de caso database-first:a base de dados primeiro

Neste estudo de caso database-first, desenhei a base de dados inteira antes de construir um único ecrã — e, dezoito meses depois, com 1.000 tabelas e o produto ainda em desenvolvimento, a base de dados nunca precisou de ser reconstruída. Nem uma vez. Este é o estudo de caso: quanto custaram aquelas primeiras semanas sem glamour e exatamente o que compraram.

O método em si — porque é que os teus dados têm de vir antes dos teus ecrãs — tem um artigo próprio: desenvolvimento database-first. Este é a prova. É fácil concordar com um método e é fácil abandoná-lo no momento em que estás impaciente por ver alguma coisa no ecrã. Por isso, eis o que aconteceu de facto quando apostei um produto inteiro em fazer primeiro a parte aborrecida: o FIKR Space, hoje com 11 produtos integrados, todos assentes numa fundação de dados desenhada antes de qualquer um deles existir.

Duas semanas e meia sem nada para mostrar

Fase um — uma semana a mapear domínios. Antes de uma única linha de código, listei todas as áreas em que o sistema alguma vez tocaria. Mais de 20 domínios no total, divididos em cinco grupos:

• Núcleo: organizações, utilizadores, equipas, permissões
• Produto: projetos, tarefas, objetivos, sprints
• Dinheiro: cap tables, rondas de investimento, transações, avaliações
• Plataforma: programas de aceleração, candidaturas, turmas, currículo
• Suporte: comentários, anexos, notificações, registos de atividade

Fase dois — uma semana a desenhar cada tabela. Todas as tabelas receberam a mesma espinha dorsal: que organização é dona do registo, quem o criou e quando, quem o alterou pela última vez e quando, e eliminações que escondem os registos em vez de os destruírem. Sobre essa espinha dorsal, cada domínio recebeu os seus campos específicos e as suas listas de estados e tipos guardadas como dados editáveis — nunca fixadas no código.

Fase três — três dias a mapear relações. Um mapa completo de como tudo se liga: que registos pertencem a quais, quais se ligam de muitos para muitos, quais — como comentários e anexos — se podem associar a qualquer coisa.

Total: cerca de duas semanas e meia. A base de dados inteira desenhada, tudo ligado — antes de existir um ecrã. Para quem olhava de fora, eu não tinha construído nada. As pessoas achavam que eu estava louco: "Porque não começas simplesmente a construir e vais descobrindo pelo caminho?" Porque eu não tinha tempo para reconstruir, nem dinheiro para desperdiçar, nem margem para erro. A base de dados tinha de ficar certa à primeira.

O livroThe Solopreneur RevolutionLuis Gonçalves sobre como construir um negócio de EUpreendedor com IA sem deixar o emprego.Quero o livro →

Estudo de caso database-first: o que a fundação comprou

Depois começou o retorno — e nunca mais parou. Eis cada grande redesenho por que o FIKR Space passou e o que cada um exigiu da base de dados:

Cinco remodelações da interface. Zero alterações à base de dados. Os ecrãs são janelas para os dados — eu podia recortar as janelas vezes sem conta porque as paredes nunca se mexeram. Essa assimetria é todo o argumento a favor do database-first: podes redesenhar completamente a tua interface; não podes redesenhar completamente a tua base de dados.

A fundação comprou mais duas coisas que nenhum dinheiro consegue acrescentar depois. Primeiro, uma fonte única de verdade: o painel e a lista de tarefas nunca podem discordar, porque todos os ecrãs fazem as mesmas perguntas às mesmas tabelas. Segundo, isolamento de clientes desde o primeiro dia: cada registo indica a organização a que pertence, por isso os dados de um cliente não podem passar para a conta de outro — e todas as funcionalidades que acrescentei desde então herdaram essa proteção automaticamente.

Como podia eu saber de antemão tudo aquilo de que ia precisar?

Não sabia. Não conhecia cada tabela com antecedência — alguns domínios evoluíram e foram acrescentados campos pelo caminho. Mas eu conhecia o sistema: uma plataforma multi-tenant para startups, investidores e aceleradoras, a lidar com dinheiro real, a precisar de permissões complexas e de trilhos de auditoria, com vários produtos a partilhar uma única fundação. Conhecer o sistema diz-te que tipos de tabelas têm de existir — entidades, relações, tabelas de referência, registos de auditoria — mesmo antes de conheceres cada campo. Quando surgiam novas necessidades, encaixavam nos padrões existentes em vez de lutarem contra eles.

Essa é a metade do trabalho que cabe ao arquiteto — a divisão completa de papéis está em tu és o arquiteto, a IA é o construtor. A IA gerou cada migração exatamente como eu a especifiquei. Não tomou nenhuma decisão de arquitetura. Pura execução. E lutou contra a disciplina o tempo todo: esquecia-se da marcação da organização, saltava índices, propunha atalhos — os sinais de alerta estão catalogados em 11 sinais de que a IA está errada com toda a confiança.

O contrafactual: quanto custa saltar esta etapa

Eis como seria a versão desta história a começar pela interface. Na primeira semana, constróis um painel bonito e crias uma tabela para o alimentar. Na segunda semana, constróis uma lista de tarefas e crias outra tabela. Na terceira semana, o painel diz 15 tarefas e a lista mostra 18 — porque agora tens duas fontes de verdade, e ninguém sabe quando divergiram nem qual delas está certa.

Agora aumenta a escala. Imagina que eu tinha saltado o isolamento de clientes e precisava de o acrescentar mais tarde: todas as tabelas alteradas, todas as consultas reescritas, todas as regras de acesso criadas, todos os dados existentes migrados. Semanas de trabalho de alto risco a mexer em tudo ao mesmo tempo — o tipo de cirurgia que mata produtos feitos a solo. Como foi desenhado desde o primeiro dia, nunca houve nada para acrescentar à pressa.

E o dinheiro? A fatura total de ferramentas para construir tudo isto foi de 3.250 € — o detalhe está em o stack de 3.250 €. O recurso caro nunca foi dinheiro. Foi a disciplina de passar duas semanas e meia nas fundações enquanto não havia nada para mostrar. Centenas de funcionalidades depois, todas a encaixar umas nas outras, continua a ser o investimento com maior retorno que alguma vez fiz num produto.

12 semanasA tua carreira corporativa nunca foi o planoCandidata-te ao Solopreneur Accelerator.Candidatar-me →

Perguntas frequentes

Porquê desenhar a base de dados inteira antes de qualquer interface?

Porque a interface pode mudar e a base de dados não — pelo menos não de forma barata. Os ecrãs são janelas para os dados; redesenha-os quantas vezes quiseres. Mas reestruturar os dados por baixo de um produto em produção significa mexer em todas as funcionalidades ao mesmo tempo. Acerta na fundação e tudo o que for construído sobre ela mantém-se de pé.

Quanto tempo demorou a desenhar a base de dados inteira?

Cerca de duas semanas e meia: uma semana a mapear mais de 20 domínios, uma semana a desenhar cada tabela com uma espinha dorsal comum e três dias a mapear as relações entre elas. É esse o preço total da fundação — comparado com dezoito meses de construção sem uma única reconstrução.

A base de dados alguma vez precisou de ser reconstruída?

Não. Nem uma vez em dezoito meses. Foram acrescentados campos e alguns domínios evoluíram, mas sempre dentro dos padrões existentes. Cinco redesenhos completos da interface — painel, navegação, layout, estilo, telemóvel — não exigiram nenhuma alteração à base de dados.

O meu produto precisa de uma base de dados deste tamanho?

Não. O tamanho reflete 11 produtos integrados a partilhar uma única fundação. O princípio funciona a qualquer escala: lista cada entidade do teu sistema, mapeia como se relacionam, desenha tudo antes de construir ecrãs. A disciplina é a mesma, quer o teu produto precise de uma dúzia de tabelas, quer de centenas.