Construyo sistemas, no piezas: diseño la siguiente fase y construyo solo la actual
Cuando empiezo algo lo pienso para que crezca: un contrato entre las partes, una capa de servicios, una costura donde encajará lo siguiente. Pero la siguiente fase se diseña, no se construye: lo que aún no hace falta no tiene tablas, campos ni servicios esperándolo. La arquitectura puede anticipar; el código, no.
Ver en el grafo¿No es demasiado sistema para lo que es?
Tira en sentido contrario a construir solo lo mínimo, y a veces el diseño anticipado acierta menos de lo que cuesta. Lo que los reconcilia es dónde se pone la anticipación: en las fronteras entre piezas, que son baratas de dibujar y caras de cambiar, no en el código de dentro.
Dónde se ve6
- Este portfolio
Un contrato de API que admite otro backend u otro frontend, y contenido en ficheros que podrá pasar a un backoffice sin cambiar lo que sirve la API; ni lo uno ni lo otro se ha construido antes de hacer falta
- Ajuntaweb 2.0
Una pieza que se justifica pero aún no hace falta se documenta como decisión y se aplaza; la migración desde la 1.0 no condiciona el diseño y se planifica al final
- Mindundi
Añadir un canal no toca el núcleo, y la lista de la compra está pensada para admitir menús y un carrito automático, sin un solo campo añadido por adelantado
- Ecosistema digital de una empresa del sector fitosanitario
La identidad común se pensó para las aplicaciones de entonces y las que vendrían: cada una nueva entró con una entrada de configuración, sin tocar el mecanismo
- Gestor de ensayos de campo
La API para agentes se diseñó para consumirse hoy con skills y mañana con un servidor MCP, sin construir el servidor antes de hacer falta
- Investigación cuantitativa de mercados
El cálculo devuelve datos para que una interfaz futura lo reutilice sin reescribirlo, pero esa interfaz no existe y nada se extrae a común hasta que lo usan dos herramientas