Lo que no debe cruzar
Dónde está la línea entre lo que pertenece al core y lo que se queda en la interfaz. Cuatro criterios, la tabla de casos frecuentes, y los dos errores simétricos: cruzar de más y cruzar de menos.
Los cuatro criterios
Los criterios 3 y 4 tiran en direcciones opuestas a propósito, y ahí está la parte interesante: el mismo trabajo cambia de lado según su tamaño. Filtrar cincuenta elementos se hace en el frontend; filtrar cincuenta mil, en el core. La línea no es conceptual: es una medida.
Los casos frecuentes
Los dos errores simétricos
Cruzar de más. Los síntomas son reconocibles: comandos que se llaman get_algo y devuelven un campo, decenas de comandos triviales, una interfaz que espera a que el core le conteste cosas que ya sabía. La causa suele ser la idea de que «todo el estado debe estar en el core», que es una regla mal recordada: el estado con consecuencias va en el core, no todo el estado.
El coste: latencia en cada interacción, un puente saturado, y un core lleno de funciones que no son de dominio sino de presentación.
Cruzar de menos. Los síntomas: reglas de negocio escritas en JavaScript, validaciones que solo existen arriba, cálculos que se rehacen en cada componente, y un core que es una capa de acceso a disco sin ninguna lógica. La causa suele ser la comodidad: el frontend es donde el ciclo es más rápido.
El coste: la lógica no se puede probar sin navegador, no se puede reutilizar desde otro binario ni desde móvil, y no está protegida: cualquiera que ejecute código en la webview puede saltársela.