En defensa de las estructuras de datos aburridas
Un modelo pequeño y explícito suele ser la abstracción más útil.
Ponle nombre a la cosa
Antes de elegir una base de datos o añadir un framework, describe el objeto del que es responsable tu sistema. ¿Qué significa? ¿Qué lo hace válido? ¿Qué cambia con el tiempo?
Una estantería de lectura puede empezar con un título, un autor, un estado de lectura y una nota. Esa estructura sencilla transmite la intención sin pedirle a un futuro lector que descifre un esquema flexible pero ambiguo.
Haz explícitos los estados
Un puñado de estados con nombre es más fácil de razonar que varios indicadores independientes. Dos booleanos pueden describir por accidente un libro como sin terminar y terminado a la vez. Un único estado evita esa ambigüedad en concreto.
type ReadingStatus = 'to-read' | 'reading' | 'finished';
type Book = {
slug: string;
title: string;
author: string;
status: ReadingStatus;
takeaway: string;
};
Cambia con pruebas
Explícito no significa permanente. Añade campos cuando un caso de uso concreto los necesite, y dale a una migración el mismo cuidado que a la nueva funcionalidad.
Un buen modelo pequeño deja un rastro de decisiones. Debería ayudar a alguien a entender qué le importa al sistema, aunque ese alguien seas tú dentro de seis meses.