La capa de presentación define cómo los humanos se conectan con un sistema, y aquí es donde las máquinas de estado finito en el front-end se vuelven la herramienta clave para que un arquitecto de software se abstraiga del cambio constante de tecnologías como React, Vue o Angular. La idea es simple: pensar en transiciones y estados antes que en frameworks.
¿Por qué un arquitecto debe abstraerse del front-end?
La avalancha de cambios en tecnologías de interfaz es real, pero tu trabajo como arquitecto es sostener decisiones que sigan siendo válidas en el largo plazo. No se trata de ignorar el front-end, se trata de no atarte a él.
Toda tecnología tiene impacto en el sistema. Lo que cambia con una buena arquitectura es el costo de reemplazarla cuando deje de servirte.
¿Qué hace un arquitecto en la capa de presentación? Define cómo el sistema reacciona a los cambios del usuario sin casarse con un framework específico, asegurando que la lógica de transición sobreviva aunque cambies React por Vue o Angular.
¿Cómo funcionan las máquinas de estado finito en el front-end?
Una máquina de estado finito modela el sistema como un conjunto de estados con transiciones predeterminadas que se disparan por eventos. Esas reglas viven dentro del modelo de dominio, no en el botón ni en el componente visual.
En la arquitectura clásica de tres capas (presentación, servicios y persistencia), la interfaz suele hablarle directo al servicio. Con máquinas de estado finito inviertes la lógica: la capa de presentación reacciona a los cambios en el modelo de estados, no al revés.
¿Qué ventajas concretas te da este patrón?
- Te abstraes de la implementación específica del framework de UI.
- Puedes correr tests globales, de integración e incluso de interacción sin tener la capa de renderización lista.
- Avanzas más rápido y conservas la opción de cambiar la tecnología de front-end más adelante.
- La lógica de negocio queda separada del componente visual.
Estos manejadores existen en muchas capas del desarrollo, desde dentro de una base de datos hasta librerías externas que gestionan estados de modelos completos. En el front-end es donde más rinden.
¿Cuándo usar micro front-ends y cuándo no?
Los micro front-ends son la analogía de los microservicios, pero en la capa de presentación. La idea es poder reemplazar implementaciones de casos de uso de forma sencilla, ya sea para orquestar aplicaciones complejas con equipos independientes o para permitir heterogeneidad de herramientas.
Puedes tener un micro front-end construido en Angular conviviendo con otro en Vue, mientras la aplicación general mantiene un tono, un estilo y un sistema de diseño únicos. Las máquinas de estado finito ayudan aquí porque definen las transiciones sin importar la tecnología de renderización ni cómo se comunique con los servicios.
¿Qué es un backend for frontend? Es un patrón donde creas APIs distintas para servir microservicios distintos según las necesidades de cada interfaz, mientras las transiciones de estado siguen manejándose de forma abstracta.
¿Cuándo los micro front-ends son sobreingeniería?
No todo proyecto los necesita. Aplicarlos fuera de contexto te suma complejidad sin retorno. Evítalos cuando:
- No tienes varios equipos trabajando en paralelo sobre el front-end.
- Las tecnologías que usas son bastante homogéneas.
- La velocidad de cambio no te obliga a probar nuevas herramientas para mantener buenos resultados.
Si ninguna de esas condiciones aplica, probablemente estás resolviendo un problema que no tienes.
¿Cómo se conectan diseño y arquitectura en sistemas complejos?
Las interfaces de usuario, la experiencia de usuario y los sistemas de diseño son complementarios a la labor de arquitectura. Sin ellos, la comunicación con el usuario se rompe, por más limpia que esté tu lógica de estados.
Una referencia útil es el libro No me hagas pensar, de Steve Krug, que recopila patrones de comunicación entre sistemas de información y personas. La idea central es reducir la carga cognitiva del usuario al interactuar con tu sistema.
En el caso del Banco Interamericano de Desarrollo, las interfaces tienen que mostrar documentos enormes, pesados, complejos y muchas veces repetitivos. Ahí el reto es generar un lenguaje visual común para perfiles muy distintos: importadores, exportadores y agentes aduaneros. Todos deben sentirse cómodos y conservar la idea general de su proceso aunque la carga visual sea fuerte.
Esa es la verdadera prueba: que la arquitectura sostenga el cambio tecnológico mientras el diseño sostiene la conversación con personas reales. ¿Cómo estás separando hoy la lógica de estados de tu framework de UI? Cuéntame en los comentarios.
