Caso práctico database-first:tablas antes que pantallas

En este caso práctico database-first diseñé la base de datos antes de construir una sola pantalla, y 18 meses después, con 1.000 tablas y todavía en desarrollo, nunca ha necesitado una reconstrucción. Ni una vez. Este es el caso: lo que costaron esas primeras semanas poco vistosas y exactamente lo que compraron.

El método en sí (por qué tus datos deben ir antes que tus pantallas) tiene su propio artículo: desarrollo database-first. Este es la prueba. Un método es fácil de aprobar con la cabeza y fácil de abandonar en cuanto te impacientas por ver algo en pantalla. Así que esto es lo que pasó de verdad cuando aposté un producto entero a hacer primero la parte aburrida: FIKR Space, hoy 11 productos integrados y más de 3 millones de líneas de código, todo sobre una base de datos diseñada antes de que existiera nada de ello.

Caso práctico database-first: dos semanas y media sin nada que enseñar

Fase uno: una semana mapeando dominios. Antes de escribir una sola línea de código, enumeré todas las áreas que el sistema llegaría a tocar. Más de 20 dominios en total, agrupados en cinco bloques:

• Núcleo: organizaciones, usuarios, equipos, permisos
• Producto: proyectos, tareas, objetivos, sprints
• Dinero: cap tables, rondas de financiación, transacciones, valoraciones
• Plataforma: programas de aceleración, solicitudes, cohortes, currículo
• Soporte: comentarios, adjuntos, notificaciones, registros de actividad

Fase dos: una semana diseñando cada tabla. Todas las tablas recibieron la misma columna vertebral: qué organización es dueña del registro, quién lo creó y cuándo, quién lo cambió por última vez y cuándo, y borrados que ocultan los registros en lugar de destruirlos. Sobre esa base, cada dominio recibió sus campos específicos y sus listas de estados y tipos guardadas como datos editables, nunca incrustadas en el código.

Fase tres: tres días mapeando relaciones. Un mapa completo de cómo se conecta todo: qué registros pertenecen a cuáles, cuáles se enlazan de muchos a muchos, cuáles (como los comentarios y los adjuntos) pueden adjuntarse a cualquier cosa.

Total: unas dos semanas y media. Toda la base, diseñada y conectada, antes de que existiera una pantalla. Para cualquiera que mirase, no había construido nada. La gente pensaba que estaba loco: "¿Por qué no empiezas a construir y lo vas resolviendo sobre la marcha?". Porque no tenía tiempo para reconstruir, ni dinero que malgastar, ni margen de error. La base de datos tenía que salir bien a la primera.

El libroThe Solopreneur RevolutionLuis Gonçalves sobre cómo crear un negocio de solopreneur con IA sin dejar tu empleo.Consigue el libro →

Lo que compró de verdad la base database-first

Entonces empezó la recompensa, y no se detuvo. Estos son todos los grandes rediseños por los que pasó FIKR Space y lo que cada uno exigió de la base de datos:

Cinco renovaciones de interfaz. Cero cambios en la base de datos. Las pantallas son ventanas a los datos: podía recortar las ventanas sin fin porque las paredes nunca se movieron. Esa asimetría es todo el argumento a favor del database-first: puedes rediseñar por completo tu interfaz; no puedes rediseñar por completo tu base de datos.

La base compró dos cosas más que el dinero no puede añadir después. Primero, una única fuente de verdad: el panel y la lista de tareas nunca pueden discrepar, porque cada pantalla hace las mismas preguntas a las mismas tablas. Segundo, aislamiento de clientes desde el primer día: cada registro nombra a la organización que lo posee, así que los datos de un cliente no pueden filtrarse a la cuenta de otro, y toda funcionalidad que he añadido desde entonces heredó esa protección automáticamente.

¿Cómo iba a saber que necesitaría 1.000 tablas?

No lo sabía. No conocía todas las tablas de antemano: algunos dominios evolucionaron y se añadieron campos por el camino. Pero conocía el sistema: una plataforma multi-tenant para startups, inversores y aceleradoras, que maneja dinero real, con permisos complejos y rastros de auditoría, y con varios productos compartiendo una misma base. Conocer el sistema te dice qué tipos de tablas tienen que existir (entidades, relaciones, tablas de consulta, registros de auditoría) incluso antes de conocer cada campo. Cuando aparecieron nuevas necesidades, encajaron en los patrones existentes en lugar de pelearse con ellos.

Esa es la mitad del arquitecto en el trabajo; el reparto completo de papeles está en tú eres el arquitecto, la IA es el constructor. La IA generó cada migración exactamente como la especifiqué. No tomó ninguna decisión de arquitectura. Ejecución pura. Y peleó con la disciplina constantemente: olvidaba la etiqueta de organización, se saltaba los índices, proponía atajos; las señales de alarma están catalogadas en 11 señales de que la IA se equivoca con total seguridad.

El contrafactual: lo que cuesta saltárselo

Así se ve la versión de esta historia que empieza por la interfaz. Primera semana: construyes un panel precioso y creas una tabla que lo alimente. Segunda semana: construyes una lista de tareas y creas otra tabla. Tercera semana: el panel dice 15 tareas y la lista muestra 18, porque ahora tienes dos fuentes de verdad y nadie sabe cuándo divergieron ni cuál es la correcta.

Ahora escálalo. Imagina que me hubiera saltado el aislamiento de clientes y hubiera tenido que añadirlo después: cada tabla cambiada, cada consulta reescrita, cada regla de acceso creada, todos los datos existentes migrados. Semanas de trabajo de alto riesgo tocándolo todo a la vez: el tipo de cirugía que mata a los productos en solitario. Como estaba diseñado desde el primer día, nunca hubo nada que añadir a posteriori.

¿Y el dinero? Toda la factura de herramientas para construir todo esto fue de 3.250 €; el desglose está en el stack de 3.250 €. El insumo caro nunca fue el efectivo. Fue la disciplina de dedicar dos semanas y media a los cimientos cuando no había nada que enseñar. Cientos de funcionalidades después, todas encajando entre sí, sigue siendo la inversión de mayor retorno que he hecho en un producto.

12 semanasTu carrera corporativa nunca fue el planSolicita plaza en el Solopreneur Accelerator.Solicitar ahora →

Preguntas frecuentes

¿Por qué diseñar toda la base de datos antes que cualquier interfaz?

Porque la interfaz puede cambiar y la base de datos no, al menos no barato. Las pantallas son ventanas a los datos; rediséñalas tantas veces como quieras. Pero reestructurar los datos de debajo de un producto en producción significa tocar todas las funcionalidades a la vez. Acierta con la base y todo lo construido encima sigue en pie.

¿Cuánto tardó el diseño de la base de datos?

Unas dos semanas y media: una semana mapeando más de 20 dominios, una semana diseñando cada tabla con una columna vertebral común y tres días mapeando las relaciones entre ellas. Ese es el precio completo de la base, frente a 18 meses de construcción sin ninguna reconstrucción.

¿Tuvo que reconstruirse alguna vez la base de datos?

No. Ni una vez en 18 meses. Se añadieron campos y algunos dominios evolucionaron, pero siempre dentro de los patrones existentes. Cinco rediseños completos de interfaz (panel, navegación, maquetación, estilo, móvil) no exigieron ningún cambio en la base de datos entre todos.

¿Necesito 1.000 tablas para mi producto?

No. Esa cifra refleja 11 productos integrados que comparten una misma base. El principio se reduce a cualquier tamaño: enumera todas las entidades de tu sistema, mapea cómo se relacionan y diséñalo todo antes de construir pantallas. La disciplina es la misma ya necesite tu producto una docena de tablas o cientos.