Equipos, límites de propiedad y ley de Conway

Los microfrontends son primero una herramienta organizacional. La arquitectura funciona cuando la división entre remotos coincide con la división entre equipos, y cada pieza tiene un dueño claro.

La ley de Conway en un párrafo

En 1968 Melvin Conway observó que las organizaciones diseñan sistemas que copian su propia estructura de comunicación. Si cuatro equipos construyen un frontend, el frontend tiende a terminar con cuatro partes, y las interfaces entre las partes se parecen a las conversaciones entre los equipos.

En microfrontends esto funciona en ambas direcciones. Si los remotos siguen la estructura de los equipos, cada equipo puede trabajar solo la mayor parte del tiempo. Si la cruzan, cada cambio necesita una reunión. Por eso mismo la arquitectura tiene poco sentido para un solo equipo, como se explica en cuándo usar microfrontends.

Divide por dominio de negocio

La unidad de un microfrontend es un área de negocio que un usuario reconocería: pedidos, facturación, catálogo, atención al cliente. Cada una tiene sus pantallas, sus datos y su roadmap.

Divisiones que fallan:

• Por capa técnica. Un remoto para componentes, otro para acceso a datos. Cada funcionalidad los toca todos.
• Por fragmento de página. Un remoto para el encabezado, otro para una tabla, otro para un formulario. Los equipos tienen que coordinarse en cada pantalla.

Una prueba útil para un límite: ¿puede el equipo entregar una funcionalidad típica de esta área sin cambiar ningún otro remoto? Si la respuesta suele ser sí, el límite es bueno.

Un remoto, un dueño

Cada remoto tiene exactamente un equipo dueño. Ese equipo:

• Decide qué se construye y cuándo se publica.
• Es dueño del pipeline y de la salud del área en producción.
• Recibe sus alertas.
• Revisa cada cambio en su código.

Un equipo puede ser dueño de más de un remoto. Un remoto compartido por dos equipos, en la práctica, no tiene dueño. Si dos equipos necesitan cambiar el mismo remoto con frecuencia, el límite está mal o los dos equipos deberían ser uno.

Deja la propiedad por escrito: una tabla de rutas, remotos y equipos, guardada junto al manifiesto. Los archivos de code owners en los repositorios la hacen exigible.

Qué hace el equipo de plataforma

Los equipos autónomos necesitan una base común. Un equipo de plataforma la entrega como un producto interno:

• El host: layout, navegación, sesión y carga de remotos.
• El contrato entre host y remotos, y su versionado.
• El design system, o una colaboración cercana con el equipo que lo tiene.
• Plantillas de pipeline, generadores de proyectos y la política de dependencias compartidas.
• Monitoreo que atribuya errores y rendimiento a cada remoto.
• Documentación y soporte para los equipos de producto.

Lo que debe evitar:

• Construir funcionalidades de negocio.
• Aprobar cada publicación. Si el equipo de plataforma es una compuerta, el cuello de botella solo cambió de lugar.

En una organización pequeña, el equipo de plataforma pueden ser dos personas a tiempo parcial. Lo que importa es que el rol exista y tenga tiempo asignado.

Señales de un monolito distribuido

Un monolito distribuido tiene los costos de los microfrontends y el acoplamiento de una sola app. Las señales se ven en la forma de trabajar de los equipos antes de aparecer en el código:

Cómo evitarlo

• Mantén delgado el código compartido. Comparte el design system, el contrato y las utilidades técnicas. La lógica de negocio se queda dentro de su área, aunque cueste algo de duplicación.
• Comunica con contratos explícitos. Navegación, un conjunto pequeño de eventos y el backend. Mira comunicación entre microfrontends.
• Mantén la compatibilidad hacia atrás. Un remoto debe funcionar con la versión anterior del host y de sus vecinos. Eso es lo que permite publicar por separado.
• Revisa los límites cuando cambien los equipos. Una reorganización que mueve responsabilidades también debe mover código. Si no lo hace, la arquitectura describe una empresa que ya no existe.

Dar forma a los equipos a propósito

La ley de Conway se puede usar de forma deliberada: decide la arquitectura que quieres y después organiza los equipos para que coincidan con ella. Si quieres que facturación sea independiente, crea un equipo dueño de facturación de punta a punta, idealmente con su API de backend incluida.

Esto también pone un límite. La cantidad de remotos debe seguir a la cantidad de equipos que pueden ser sus dueños. Diez remotos para tres equipos significa que la mayoría no tiene un dueño real, y se paga la sobrecarga sin el beneficio. Dividir demasiado es el primer punto de errores comunes en microfrontends.

Más en esta sección

• El costo real de los microfrontends
• Errores comunes en microfrontends y cómo evitarlos
• Checklist de preparación para microfrontends
• Seguridad en microfrontends: qué cambia y qué hacer