El criterio de elección: peso, dominio, herramientas y equipo

Conviene decir con precisión qué decide esta lección y qué no, porque el track ya contiene un criterio parecido y confundirlos arruina los dos. Aquel del nivel ocho respondía a una pregunta anterior: si tu problema tiene forma de máquina o si te la estabas imaginando. Este da esa respuesta por hecha y se ocupa de la siguiente, que es puramente instrumental y sin embargo se discute con una carga ideológica desproporcionada: qué ejecuta tu máquina. La tesis es que la elección se decide con cuatro medidas honestas y una decisión estructural que hace reversible el error, y que quien diseña esa reversibilidad puede permitirse equivocarse, mientras que quien la ignora tendrá razón o no durante los próximos tres años sin posibilidad de revisión barata.

Los cuatro ejes, medidos y no opinados

Cada eje se puede convertir en una medida concreta. Si no puedes producir el número o la lista que cada uno pide, todavía no estás decidiendo: estás prefiriendo.

El peso, en su contexto. La cifra publicada de un paquete es irrelevante por sí sola; lo que importa es su fracción del presupuesto de la ruta que la carga y si esa ruta está en el camino crítico del primer pintado. Un motor completo en una aplicación interna que ya descarga varios megabytes de tablas y gráficos es ruido estadístico. El mismo motor en un formulario incrustado en la página de un tercero puede ser inaceptable. Y hay un factor multiplicativo que casi nadie contabiliza: el coste marginal de la segunda máquina en un motor ya cargado es cero, así que la comparación correcta nunca es una máquina contra un motor, sino todas tus máquinas presentes y previsibles contra ese motor.

Las capacidades discriminantes. Solo cinco cosas separan de verdad a un motor completo de todo lo demás, y ninguna es opinable: jerarquía de estados anidados, regiones paralelas ortogonales, estados de historia, transiciones diferidas por tiempo declaradas y actores invocados con ciclo de vida gestionado. Haz la lista de cuáles usa tu problema hoy. Si son cero, cualquier alternativa ligera basta. Si son dos o más, escribirlas a mano es reimplementar un motor peor.

La legibilidad del grafo. Esta es la que más decisiones voltea cuando se plantea bien. Pregunta quién necesita leer la máquina además del intérprete: una persona de producto que valida el flujo, un generador de pruebas basadas en modelo, alguien que audita un proceso regulado, tú mismo dentro de un año. Solo las definiciones que son dato pueden ser leídas por herramientas; las compuestas con funciones solo pueden ejecutarse.

El segundo lector. El eje humano no es el blando de los cuatro, es el más caro. Un vocabulario conocido traslada el coste de aprendizaje a documentación pública y a conocimiento previo; un intérprete casero lo concentra en la única persona que lo escribió. La pregunta operativa es cuántas personas van a modificar esta máquina en dos años y cuánto tarda cada una en estar en condiciones de hacerlo sin romper nada.

Existe además un quinto eje que se cuela sin invitación en casi todas estas conversaciones y que conviene desactivar por escrito: la popularidad. El número de estrellas de un repositorio no es una capacidad, no reduce el peso y no hace más legible tu grafo; a lo sumo es un indicador indirecto y ruidoso del eje del segundo lector, porque una herramienta extendida es más fácil de contratar y de documentar. Úsalo solo así, como aproximación imperfecta de un eje que ya tienes medido mejor, y nunca como argumento independiente. La versión honesta de la frase la librería más usada es simplemente hay más gente que ya sabe leerla, y eso ya lo estabas contando.

La tabla de decisión

flowchart TD
A[ya sabes que tu problema es una maquina] --> B[cuantas capacidades discriminantes usa?]
B -->|dos o mas| C[motor completo]
B -->|una| D[motor completo o revisar el modelo]
B -->|ninguna| E[alguien fuera del codigo debe leer el grafo?]
E -->|si| F[definicion como dato: tabla propia o motor completo]
E -->|no| G[el presupuesto de descarga es critico?]
G -->|si| H[tabla a mano o libreria ligera]
G -->|no| I[reducer como maquina o almacen tipado]
style C fill:#cba6f7,color:#11111b
style H fill:#a6e3a1,color:#11111b
style I fill:#89dceb,color:#11111b

La hoja que más gente sorprende es la de una sola capacidad discriminante, porque no manda al motor sin más: manda a revisar el modelo. Una única región paralela suele ser dos máquinas independientes que alguien juntó sin necesidad, y un único estado de historia suele ser un campo de contexto que recuerda la última pestaña. Antes de adoptar un motor por una sola capacidad, comprueba si esa capacidad es del dominio o es un artefacto de haber modelado junto lo que estaba separado.

La frontera que hace reversible el error

Todo lo anterior sirve de poco sin la decisión estructural que convierte la elección en algo revisable. Consiste en no dejar que el motor se filtre por la aplicación: la máquina y su intérprete viven detrás de un módulo que expone un contrato mínimo —el estado actual, el envío de eventos y la consulta de qué es legal ahora— y nadie fuera de ese módulo importa nada del motor.

export type EventoPedido = { type: 'PEDIR' } | { type: 'CANCELAR' } | { type: 'REINTENTAR' }
export type FasePedido = 'inactivo' | 'cargando' | 'listo' | 'fallo'

export type Flujo = {
  fase: FasePedido
  enviar: (e: EventoPedido) => void
  puede: (t: EventoPedido['type']) => boolean          // legalidad, sin exponer el motor
}

export function useFlujoPedido(): Flujo {
  const [snapshot, send] = useActor(maquinaPedido)      // unica linea acoplada al motor
  return {
    fase: snapshot.value as FasePedido,
    enviar: send,
    puede: (t) => snapshot.can({ type: t } as EventoPedido),
  }
}

La prueba de que la frontera funciona es poder implementar el mismo contrato con la opción vecina sin que nada de fuera se entere. Escribirlo una vez, aunque no lo uses, es la manera más barata de verificar que el acoplamiento está donde crees.

// mismo contrato, cero dependencias: la frontera es la unidad de reversibilidad
export function useFlujoPedidoSinMotor(): Flujo {
  const [fase, despachar] = useReducer(transicion, 'inactivo' as FasePedido)
  return {
    fase,
    enviar: (e) => despachar(e),
    puede: (t) => transicion(fase, { type: t } as EventoPedido) !== fase,
  }
}

Fíjate en cómo puede se deriva aquí de la propia función de transición: si aplicar el evento no mueve la fase, el evento no era legal. Esa equivalencia solo se sostiene mientras no existan transiciones internas que cambien contexto sin cambiar de estado, y detectar esa limitación al escribir la implementación alternativa es exactamente el tipo de hallazgo que la frontera está para producir antes de que sea urgente.

El valor de esa frontera es medible: si mañana decides que el motor sobraba y quieres bajar a una tabla propia, o que la tabla se quedó corta y quieres subir al motor, cambias un archivo y las pruebas del contrato te dicen si acertaste. Sin frontera, el motor aparece en cada componente que consulta un estado, y la migración deja de ser una tarde para convertirse en un proyecto que nadie aprueba. Fíjate además en puede: exponer la legalidad como consulta en vez de que cada componente reconstruya sus propias condiciones es lo que impide que la lógica de la máquina se filtre en forma de condicionales dispersos.

Con esto se cierra el nivel de las alternativas, y su recorrido tiene una forma deliberada: empezó midiendo el suelo a mano para tener una referencia honesta, pasó por el motor que ya venía instalado en el framework, recorrió la franja ligera para entender qué se paga con los kilobytes, y estudió en Zag el caso donde la máquina es el activo duradero de toda una industria. Las cinco lecciones responden a la misma pregunta desde ángulos distintos, y por eso el criterio de esta última no es un apéndice: es la única forma de que las cuatro anteriores no se conviertan en preferencias.