Caso di studio database-first:tabelle prima delle schermate

In questo caso di studio database-first ho progettato il database prima di costruire una sola schermata, e 18 mesi dopo, con 1.000 tabelle e ancora in sviluppo, non ha mai avuto bisogno di essere ricostruito. Nemmeno una volta. Questo è il caso di studio: quanto sono costate quelle prime settimane poco affascinanti, e cosa hanno comprato esattamente.

Il metodo in sé, cioè perché i dati vengono prima delle schermate, ha il suo articolo: lo sviluppo database-first. Questo ne è la prova. Un metodo è facile da approvare con un cenno e facile da abbandonare appena hai fretta di vedere qualcosa sullo schermo. Ecco allora cosa è successo davvero quando ho scommesso un intero prodotto sul fare prima la parte noiosa: FIKR Space, oggi 11 prodotti integrati e più di 3 milioni di righe di codice, tutti poggiati su una base dati progettata prima che esistesse qualsiasi altra cosa.

Caso di studio database-first: due settimane e mezzo senza niente da mostrare

Fase uno: una settimana a mappare i domini. Prima di una sola riga di codice, ho elencato ogni area che il sistema avrebbe mai toccato. Più di 20 domini in totale, divisi in cinque gruppi:

• Core: organizzazioni, utenti, team, permessi
• Prodotto: progetti, attività, obiettivi, sprint
• Denaro: cap table, round di finanziamento, transazioni, valutazioni
• Piattaforma: programmi di accelerazione, candidature, coorti, curriculum
• Supporto: commenti, allegati, notifiche, registri delle attività

Fase due: una settimana a progettare ogni tabella. Ogni tabella ha ricevuto la stessa struttura portante: quale organizzazione possiede il record, chi lo ha creato e quando, chi lo ha modificato per ultimo e quando, e cancellazioni che nascondono i record invece di distruggerli. Su questa struttura, ogni dominio ha avuto i propri campi specifici e le proprie liste di stati e tipi, salvate come dati modificabili e mai incorporate nel codice.

Fase tre: tre giorni a mappare le relazioni. Una mappa completa di come tutto si collega: quali record appartengono a quali, quali si legano in modo molti-a-molti, quali, come commenti e allegati, possono agganciarsi a qualsiasi cosa.

Totale: circa due settimane e mezzo. L'intera base, progettata e collegata, prima che esistesse una sola schermata. Per chi guardava, non avevo costruito niente. La gente pensava che fossi pazzo: "Perché non inizi a costruire e vedi strada facendo?" Perché non avevo tempo per ricostruire, né soldi da sprecare, né margine di errore. Il database doveva essere giusto al primo colpo.

Il libroThe Solopreneur RevolutionLuis Gonçalves su come costruire un'attività da solopreneur con l'IA mentre sei ancora dipendente.Scopri il libro →

Cosa ha comprato davvero la base database-first

Poi i frutti hanno iniziato ad arrivare, e non si sono più fermati. Ecco ogni grande rifacimento attraversato da FIKR Space e cosa ha richiesto al database:

Cinque rifacimenti della UI. Zero modifiche al database. Le schermate sono finestre sui dati: potevo ritagliare le finestre all'infinito perché i muri non si sono mai spostati. Questa asimmetria è tutta la ragione del database-first: puoi ridisegnare completamente la tua UI; non puoi ridisegnare completamente il tuo database.

La base ha comprato altre due cose che i soldi non possono aggiungere a posteriori. Primo, un'unica fonte di verità: la dashboard e l'elenco attività non possono mai essere in disaccordo, perché ogni schermata pone le stesse domande alle stesse tabelle. Secondo, l'isolamento dei clienti fin dal primo giorno: ogni record nomina l'organizzazione che lo possiede, quindi i dati di un cliente non possono finire nell'account di un altro, e ogni funzionalità aggiunta da allora ha ereditato quella protezione in automatico.

Come potevo sapere che mi sarebbero servite 1.000 tabelle?

Non lo sapevo. Non conoscevo in anticipo ogni tabella: alcuni domini sono evoluti e lungo la strada sono stati aggiunti dei campi. Ma conoscevo il sistema: una piattaforma multi-tenant per startup, investitori e acceleratori, che gestisce denaro vero, richiede permessi complessi e tracce di audit, con più prodotti che condividono una sola base. Conoscere il sistema ti dice che tipi di tabelle devono esistere (entità, relazioni, tabelle di lookup, log di audit) anche prima di conoscere ogni campo. Quando sono emerse nuove esigenze, si sono incastrate negli schemi esistenti invece di combatterli.

Questa è la metà del lavoro che spetta all'architetto: la divisione completa dei ruoli è in tu sei l'architetto, l'AI è il costruttore. L'AI ha generato ogni migrazione esattamente come l'avevo specificata. Non ha preso nessuna decisione architetturale. Pura esecuzione. E ha combattuto continuamente la disciplina: dimenticava l'etichetta dell'organizzazione, saltava gli indici, proponeva scorciatoie. I segnali d'allarme sono catalogati in 11 segnali che l'AI sbaglia con sicurezza.

Lo scenario alternativo: quanto costa saltare tutto questo

Ecco come appare la versione di questa storia con la UI al primo posto. Prima settimana: costruisci una bella dashboard e crei una tabella per alimentarla. Seconda settimana: costruisci un elenco attività e crei un'altra tabella. Terza settimana: la dashboard dice 15 attività e l'elenco ne mostra 18, perché ora hai due fonti di verità e nessuno sa quando hanno divergito né quale sia quella giusta.

Ora scala il tutto. Supponi che avessi saltato l'isolamento dei clienti e dovessi aggiungerlo dopo: ogni tabella modificata, ogni query riscritta, ogni regola di accesso creata, tutti i dati esistenti migrati. Settimane di lavoro ad alto rischio che tocca tutto insieme: il tipo di intervento chirurgico che uccide i prodotti di un fondatore solitario. Siccome era progettato fin dal primo giorno, non c'è mai stato niente da rimediare.

E i soldi? L'intero conto degli strumenti per costruire tutto questo è stato di 3.250 €: il dettaglio è nello stack da 3.250 €. L'input costoso non è mai stato il denaro. È stata la disciplina di dedicare due settimane e mezzo alle fondamenta quando non c'era niente da mostrare. Centinaia di funzionalità dopo, tutte incastrate tra loro, resta l'investimento a più alto rendimento che abbia mai fatto in un prodotto.

12 settimaneLa carriera aziendale non è mai stata il pianoCandidati al Solopreneur Accelerator.Candidati ora →

Domande frequenti

Perché progettare l'intero database prima di qualsiasi UI?

Perché la UI può cambiare e il database no, almeno non a basso costo. Le schermate sono finestre sui dati: ridisegnale quanto vuoi. Ma ristrutturare i dati sotto un prodotto già online significa toccare ogni funzionalità insieme. Se la base è giusta, tutto ciò che ci costruisci sopra resta in piedi.

Quanto tempo ha richiesto progettare il database?

Circa due settimane e mezzo: una settimana per mappare più di 20 domini, una settimana per progettare ogni tabella con una struttura portante condivisa e tre giorni per mappare le relazioni tra loro. È il prezzo completo della base, misurato su 18 mesi di sviluppo senza ricostruzioni.

Il database ha mai avuto bisogno di essere ricostruito?

No. Nemmeno una volta in 18 mesi. Sono stati aggiunti campi e alcuni domini sono evoluti, ma sempre dentro gli schemi esistenti. Cinque redesign completi della UI (dashboard, navigazione, layout, stile, mobile) non hanno richiesto, tutti insieme, alcuna modifica al database.

Servono 1.000 tabelle per il mio prodotto?

No. Quel numero riflette 11 prodotti integrati che condividono una sola base. Il principio vale a qualsiasi scala: elenca ogni entità del tuo sistema, mappa come si collegano, progetta tutto prima di costruire le schermate. La disciplina è la stessa che il tuo prodotto abbia bisogno di una dozzina di tabelle o di centinaia.