¿Cómo desacoplarías la lógica de negocio del framework en una aplicación Vue grande?

Respuesta

• Saca reglas, validaciones y casos de uso a módulos TypeScript sin dependencias de Vue para que puedan probarse y evolucionar fuera de la UI.
• Haz que composables y stores orquesten flujo y transporte, pero evita que decidan reglas de negocio que deberían vivir en una capa más estable.
• Transforma DTOs del backend en la frontera para no propagar contratos externos por toda la interfaz.

Puntos clave

• La decisión correcta en Vue casi siempre depende del alcance del problema: componente, subárbol, feature o aplicación completa.
• Una buena arquitectura deja dependencias visibles, reduce puntos de escritura y mantiene cerca del caso de uso lo que cambia junto.
• Si una solución necesita demasiadas capas para explicar algo pequeño, probablemente está modelando peor el problema, no mejor.

Errores comunes

• Crear una capa “shared” enorme donde cabe todo acaba destruyendo justo el aislamiento que se buscaba.
• Escoger mecanismo por moda en vez de por alcance suele dejar soluciones más difíciles de leer que de cambiar.

Ejemplo de código

type DecisionRecord = {
  title: string;
  context: string;
  chosenOption: string;
  consequences: string[];
};

const record: DecisionRecord = {
  title: "Adoptar Pinia para estado compartido",
  context: "Duplicidad de lógica entre pantallas y composables",
  chosenOption: "Pinia solo para flujos cruzados",
  consequences: ["menos acoplamiento", "migración incremental"],
};

Ejemplo o caso real

Esto suele aparecer en features vivas del producto donde cada cambio pequeño empieza a tocar demasiados componentes, composables o stores.

Idea clave

La mejor arquitectura en Vue es la que reduce dependencias hoy y sigue siendo explicable mañana.