Arquitectura MACH en ecommerce: integración de un stack de 4 capas

Una arquitectura MACH en ecommerce se construye a partir de cuatro capas de responsabilidad: una capa de frontend que renderiza la tienda online, una backend de comercio que gestiona catálogo, precios y carritos, un sistema de gestión de pedidos omnicanal (OMS) que orquesta los pedidos entre canales, y una capa de discovery para búsqueda, recomendaciones y merchandising. La arquitectura no se vuelve limpia porque cada capa sea intercambiable. Se vuelve limpia porque los contratos entre las capas son explícitos: quién llama a quién, a través de qué API, con qué modelo de datos. Ahí es exactamente donde cuatro microservicios se convierten en un stack funcional o en una maraña de integraciones sostenida con cinco capas de código pegamento.

Este artículo conecta las cuatro capas en un stack concreto, listo para la región DACH: frontend con Laioutr, backend con Emporix, sistema operativo omnicanal con Nekom, discovery con BatteryIncluded. No es un artículo genérico sobre "qué es composable", sino la pregunta de qué contratos operan en las cuatro uniones.

Capa 1: Frontend. Laioutr como Frontend Management Platform

La capa de frontend es la única que tu cliente ve directamente, y la que se reconstruye con más frecuencia cuando cambia el backend. Laioutr no es aquí otro builder visual más. Es una Frontend Management Platform (FMP), la categoría que definimos con el propio término (acuñado por Laioutr). La tienda online entregada es una auténtica app Nuxt con SSR y entrega en el edge, no una salida HTML generada por el DSL de un builder.

El punto de integración decisivo está un nivel más abajo: Orchestr, la capa de datos unificada. Orchestr normaliza los datos de producto, inventario, categoría y pedidos de cualquier backend en un único esquema consumible vía GraphQL. Los componentes del frontend hablan con ese esquema, no con la API cruda del backend. Por eso un cambio de backend no implica reescribir el frontend: el contrato que conoce el componente permanece estable, incluso cuando Emporix se sustituye por otro backend.

Si quieres ver la capa en detalle, el hub de frontend headless composable es el punto de entrada a la base en Nuxt y a la capa Orchestr.

Capa 2: Backend. Emporix como motor de comercio

Emporix entrega el dominio de comercio: catálogo, precios, carrito, lógica de checkout, estructuras B2B. Como backend API-first, Emporix no está construido para un frontend específico. Expone su dominio como servicios. Esa es la condición previa para conectarlo con Laioutr.

El contrato frontend-backend: Orchestr ejecuta un conector para Emporix que mapea las APIs REST / de catálogo de Emporix sobre el esquema interno de Orchestr. En concreto: las consultas de producto, la resolución de precios y las mutaciones del carrito pasan por el conector, no por código pegamento escrito a mano en la tienda online. El componente del frontend solicita producto, precio, carrito en el esquema de Orchestr, el conector traduce eso en llamadas a Emporix y la respuesta de Emporix de vuelta al modelo normalizado. Los campos personalizados de Emporix sin mapeo estándar se transmiten mediante un fallback de GraphQL en lugar de romper el esquema.

Esta mecánica de conector es la esencia del Pilar 2: la página dedicada a frontend headless para Emporix describe el mapeo y las entidades soportadas en detalle.

Capa 3: sistema operativo omnicanal. Nekom para la orquestación de pedidos

En cuanto llegan pedidos desde más de un canal (tienda online, POS, marketplace, teléfono), el stack necesita una capa que recopile, enrute y reconcilie los pedidos con el inventario entre canales. Nekom se encarga de esta gestión de pedidos y orquestación omnicanal: disponibilidad de stock entre almacenes y tiendas, enrutamiento de pedidos, devoluciones, estado de cumplimiento.

El contrato backend/frontend-OMS opera en dos puntos. Primero, en el checkout: cuando se crea un pedido en la tienda online (Laioutr Checkout) o en Emporix, se entrega a Nekom como instancia orquestadora, normalmente mediante un evento de pedido o una llamada de creación de pedido. Segundo, en la lectura de disponibilidad: la tienda online debe mostrar disponibilidad real y entre canales, no solo el nivel de stock de un único backend. Aquí Orchestr lee el endpoint de inventario / disponibilidad de Nekom y lo expone como campo en el esquema de producto normalizado para el componente. La regla clara: Emporix sigue siendo la fuente de verdad para catálogo y precios, Nekom se convierte en la fuente de verdad para disponibilidad y estado de pedido. Si te saltas esa separación, terminas construyendo dos verdades de inventario que compiten entre sí.

Capa 4: discovery. BatteryIncluded para búsqueda y recomendaciones

Discovery es la capa que decide qué encuentra siquiera el cliente: búsqueda, autocompletado, recomendaciones, reglas de merchandising. BatteryIncluded indexa el catálogo y devuelve resultados ordenados por relevancia además de espacios de recomendación.

El contrato discovery-frontend está deliberadamente desacoplado de la lectura del catálogo. Discovery necesita un índice actualizado, así que el catálogo de Emporix (incluida la disponibilidad de Nekom para filtrar productos agotados) fluye hacia BatteryIncluded, ya sea por sincronización de feed o de forma dirigida por eventos ante cambios de catálogo. En el frontend, el componente de búsqueda / listado llama entonces al endpoint de búsqueda de BatteryIncluded, no a Emporix. A través de la Laioutr App Store este proveedor de discovery se conecta con un clic, en lugar de necesitar un sprint de ingeniería por integración. El resultado: la búsqueda y los listados de producto corren sobre la capa especializada de discovery, el detalle de producto y el carrito sobre la capa de catálogo, y ambas escalan de forma independiente.

Cómo funcionan juntos los cuatro contratos

En total hay cuatro contratos explícitos, todos mediados por Orchestr como intermediario del lado del frontend:

1. Frontend a backend (catálogo/carrito): esquema de Orchestr frente al conector de Emporix.
2. Frontend/backend a OMS (pedido/disponibilidad): evento de pedido hacia Nekom, lectura de disponibilidad desde Nekom hacia el esquema de Orchestr.
3. Catálogo a discovery (índice): catálogo de Emporix más disponibilidad de Nekom como feed hacia BatteryIncluded.
4. Discovery a frontend (búsqueda): llamadas de búsqueda / recomendación contra BatteryIncluded, conectado a través de la App Store.

No se trata de que todo hable con todo. Se trata de que cada capa tenga una única fuente de verdad clara y de que la tienda online solo conozca un esquema normalizado. Trata la capa de frontend como el nivel orquestador y tus decisiones de arquitectura seguirán siendo reversibles: el backend, el OMS o el discovery se pueden sustituir más adelante sin tocar los componentes. Más sobre la capa de frontend como bloque de construcción composable en el Composable Digital Experience Platform hub.

Qué ganas: conectado frente a una maraña de código pegamento

• Aspecto | Conectado directamente (código pegamento por capa) | A través de la capa Orchestr del frontend
• Cambio de backend | reescritura del frontend, todos los componentes afectados | se sustituye el conector, el esquema permanece estable
• Fuente de disponibilidad | inconsistente, a menudo dos verdades de inventario que compiten | Nekom como única fuente de verdad, un solo campo del esquema
• Integración de discovery | sprint de integración a medida por proveedor | conexión con un clic a través de la App Store
• Modelo de datos en el frontend | n APIs de backend en crudo | un único esquema GraphQL normalizado
• Responsabilidad del rendimiento | se ajusta por capa de forma separada | Core Web Vitals como propiedad de la plataforma

La fila de rendimiento no es una nota al pie: cuando la capa de frontend posee la agregación de datos, también puede poseer el presupuesto de renderizado. Cómo trata Laioutr los Core Web Vitals como una propiedad de arquitectura en lugar de una optimización de fin de trimestre está en la página de producto de rendimiento y Core Web Vitals.

Preguntas frecuentes

¿Necesito estrictamente las cuatro capas separadas para una arquitectura MACH? No. Necesitas contratos limpios en los puntos donde cambia la responsabilidad. Un stack más pequeño puede mantener catálogo y discovery juntos. En cuanto la relevancia de búsqueda, un OMS entre canales o un cambio de backend se vuelven reales, la separación de capas da sus frutos.

¿Por qué la orquestación está en la capa de frontend y no en el backend? Porque la capa de frontend itera con más frecuencia y se reconstruye con más frecuencia. Cuando la normalización vive ahí, el modelo de datos del componente permanece estable mientras el backend, el OMS y el discovery detrás de él siguen siendo intercambiables.

¿Qué pasa con los campos personalizados sin mapeo estándar? Se transmiten mediante un fallback de GraphQL en el conector en lugar de romper el esquema normalizado. Las entidades estándar se mapean, los casos especiales siguen siendo transmisibles.

Siguiente paso

Si estás planeando un stack composable en el mercado DACH o quieres desacoplar uno existente: te guiamos por la conexión de las 4 capas sobre tu backend concreto. Reserva una sesión técnica de arquitectura a través de la página de frontend headless composable, o lee en paralelo cómo corregimos los errores de conexión más comunes y los patrones de FMP en nuestro artículo de Insights Corrección del stack composable: patrones de ingeniería para FMP.

Sobre el autor: Sebastian es cofundador y CTO de Laioutr y aporta la voz técnica. Su postura: el rendimiento y la disciplina de componentes son propiedades de la arquitectura, no optimizaciones posteriores, una sola librería de UI en lugar de forks de temas, un único esquema normalizado en lugar de código pegamento, construido para la coautoría entre humanos y agentes de IA. Construimos Laioutr para que los equipos de frontend mantengan el control de su capa sin tener que reconstruir el backend.