Architettura MACH nell'ecommerce: integrazione dello stack a 4 livelli

Un'architettura MACH nell'ecommerce si costruisce a partire da quattro livelli di responsabilità: un livello frontend che rende il negozio online, un backend di commerce che gestisce catalogo, prezzi e carrelli, un sistema di gestione ordini omnicanale (OMS) che orchestra gli ordini tra i canali, e un livello di discovery per ricerca, raccomandazioni e merchandising. L'architettura non diventa pulita perché ogni livello è sostituibile. Diventa pulita perché i contratti tra i livelli sono espliciti: chi chiama chi, su quale API, con quale modello di dati. È esattamente qui che quattro microservizi diventano uno stack funzionante oppure un groviglio di integrazioni tenuto insieme da cinque livelli di codice collante.

Questo articolo collega i quattro livelli su uno stack concreto, pronto per il mercato DACH: frontend con Laioutr, backend con Emporix, OS omnicanale con Nekom, discovery con BatteryIncluded. Non un pezzo generico su "cos'è il composable", ma la domanda su quali contratti girano ai quattro punti di giunzione.

Livello 1, Frontend: Laioutr come Frontend Management Platform

Il livello frontend è l'unico che il cliente vede direttamente, ed è quello che viene ricostruito più spesso quando il backend cambia. Laioutr non è un altro visual builder qui. È una Frontend Management Platform (FMP), la categoria che definiamo con questo stesso termine (coniato da Laioutr). Il negozio online consegnato è una vera app Nuxt con SSR e distribuzione edge, non un output HTML generato da un DSL di builder.

Il punto di integrazione decisivo si trova un livello più in basso: Orchestr, il livello dati unificato. Orchestr normalizza dati di prodotto, inventario, categoria e ordine da qualsiasi backend in un unico schema consumabile via GraphQL. I componenti frontend parlano con quello schema, non con l'API grezza del backend. Ecco perché un cambio di backend non è una riscrittura del frontend: il contratto che il componente conosce resta stabile, anche quando Emporix dietro le quinte viene sostituito con un backend diverso.

Se vuoi vedere il livello nel dettaglio, la composable headless frontend hub è il punto d'ingresso verso le fondamenta Nuxt e il livello Orchestr.

Livello 2, Backend: Emporix come motore di commerce

Emporix fornisce il dominio di commerce: catalogo, prezzi, carrello, logica di checkout, strutture B2B. Come backend API-first, Emporix non è costruito per un frontend specifico. Espone il proprio dominio come servizi. Questa è la precondizione per collegarlo a Laioutr.

Il contratto frontend-backend: Orchestr esegue un connettore Emporix che mappa le API REST / catalogo di Emporix sullo schema interno di Orchestr. Concretamente: query di prodotto, risoluzione dei prezzi e mutazioni del carrello passano attraverso il connettore, non attraverso codice collante scritto a mano nel negozio online. Il componente frontend richiede prodotto, prezzo, carrello nello schema Orchestr, il connettore lo traduce in chiamate Emporix e la risposta di Emporix di nuovo nel modello normalizzato. I campi custom di Emporix senza una mappatura standard passano attraverso un fallback GraphQL invece di rompere lo schema.

Questa meccanica di connettore è la sostanza del Pillar 2: la pagina dedicata headless frontend per Emporix descrive la mappatura e le entità supportate nel dettaglio.

Livello 3, OS omnicanale: Nekom per l'orchestrazione degli ordini

Non appena gli ordini arrivano da più di un canale, negozio online, POS, marketplace, telefono, lo stack ha bisogno di un livello che raccolga, instradi e riconcili gli ordini rispetto all'inventario tra i canali. Nekom possiede questa gestione degli ordini e orchestrazione omnicanale: disponibilità di stock tra magazzini e negozi, instradamento degli ordini, resi, stato dell'evasione.

Il contratto backend/frontend-OMS opera in due punti. Primo, al checkout: quando un ordine viene creato nel negozio online (Laioutr Checkout) o in Emporix, viene passato a Nekom come istanza orchestrante, tipicamente tramite un evento d'ordine o una chiamata di creazione ordine. Secondo, alla lettura della disponibilità: il negozio online dovrebbe mostrare la disponibilità reale, cross-channel, non solo il livello di stock di un singolo backend. Qui Orchestr legge l'endpoint di inventario / disponibilità di Nekom e lo espone come campo nello schema di prodotto normalizzato per il componente. La regola è chiara: Emporix resta la fonte di verità per catalogo e prezzi, Nekom diventa la fonte di verità per disponibilità e stato dell'ordine. Salta questa separazione e ti costruisci due verità di inventario in competizione tra loro.

Livello 4, Discovery: BatteryIncluded per ricerca e raccomandazioni

La discovery è il livello che decide cosa il cliente trova: ricerca, autocompletamento, raccomandazioni, regole di merchandising. BatteryIncluded indicizza il catalogo e restituisce risultati classificati per rilevanza più slot di raccomandazione.

Il contratto discovery-frontend è deliberatamente disaccoppiato dalla lettura del catalogo. La discovery ha bisogno di un indice aggiornato, quindi il catalogo Emporix (inclusa la disponibilità Nekom per il filtro degli esauriti) confluisce in BatteryIncluded, tramite sincronizzazione a feed oppure guidato dagli eventi sulle modifiche al catalogo. Nel frontend, il componente di ricerca / listing chiama quindi l'endpoint di ricerca di BatteryIncluded, non Emporix. Tramite l'App Store di Laioutr questo provider di discovery viene collegato click-to-connect, invece di far girare uno sprint di engineering per ogni integrazione. Il risultato: ricerca e liste prodotto girano sul livello di discovery specializzato, pagina prodotto e carrello sul livello catalogo, ed entrambi scalano in modo indipendente.

Come funzionano insieme i quattro contratti

In totale ci sono quattro contratti espliciti, tutti mediati da Orchestr come broker lato frontend:

1. Frontend verso backend (catalogo/carrello): schema Orchestr contro il connettore Emporix.
2. Frontend/backend verso OMS (ordine/disponibilità): evento d'ordine verso Nekom, lettura della disponibilità da Nekom nello schema Orchestr.
3. Catalogo verso discovery (indice): catalogo Emporix più disponibilità Nekom come feed verso BatteryIncluded.
4. Discovery verso frontend (ricerca): chiamate di ricerca / raccomandazione verso BatteryIncluded, collegate via App Store.

Il punto non è che tutto parla con tutto. Il punto è che ogni livello ha una fonte di verità chiara e il negozio online conosce solo uno schema normalizzato. Tratta il livello frontend come il livello orchestrante e le tue decisioni architetturali restano reversibili, backend, OMS o discovery possono essere sostituiti in seguito senza toccare i componenti. Maggiori dettagli sul livello frontend come blocco costitutivo composable nella composable digital experience platform hub.

Cosa ci guadagni: collegato correttamente contro un groviglio di codice collante

• Aspetto | Collegato direttamente (codice collante per livello) | Tramite il livello frontend Orchestr
• Cambio di backend | riscrittura del frontend, ogni componente coinvolto | si sostituisce il connettore, lo schema resta stabile
• Fonte di disponibilità | incoerente, spesso due verità di inventario in competizione | Nekom come unica fonte di verità, un campo di schema
• Integrazione discovery | sprint di integrazione custom per provider | click-to-connect via App Store
• Modello dati nel frontend | n API backend grezze | uno schema GraphQL normalizzato
• Ownership delle performance | ottimizzato per livello separatamente | Core Web Vitals come proprietà della piattaforma

La riga sulle performance non è una nota a margine: quando il livello frontend possiede l'aggregazione dei dati, può possedere anche il budget di rendering. Il modo in cui Laioutr tratta i Core Web Vitals come una proprietà architetturale invece che come un'ottimizzazione di fine trimestre è illustrato nella performance e Core Web Vitals pagina prodotto.

FAQ

Ho davvero bisogno di separare tutti i quattro livelli per un'architettura MACH? No. Serve avere contratti puliti dove cambia la responsabilità. Uno stack più piccolo può tenere catalogo e discovery insieme. Non appena la rilevanza di ricerca, un OMS cross-channel o un cambio di backend diventano concreti, la separazione dei livelli si ripaga.

Perché l'orchestrazione si trova nel livello frontend e non nel backend? Perché il livello frontend itera più spesso e viene ricostruito più spesso. Quando la normalizzazione si trova lì, il modello dati dei componenti resta stabile mentre backend, OMS e discovery dietro di esso rimangono sostituibili.

Cosa succede ai campi custom senza una mappatura standard? Passano attraverso un fallback GraphQL nel connettore invece di rompere lo schema normalizzato. Le entità standard vengono mappate, i casi speciali restano transitabili.

Prossimo passo

Se stai pianificando uno stack composable nel mercato DACH o vuoi disaccoppiarne uno esistente, ti guidiamo attraverso il collegamento a 4 livelli sul tuo backend concreto. Prenota una sessione di architettura tecnica tramite la pagina composable headless frontend, oppure leggi in parallelo come correggiamo i tipici errori di collegamento e i pattern FMP nel nostro articolo Insights Composable Stack Correction: engineering patterns for FMP.

Sull'autore: Sebastian è co-fondatore e CTO di Laioutr e presta la voce tecnica al brand. La sua posizione: la disciplina su performance e componenti è una proprietà architetturale, non un'ottimizzazione a valle, una sola libreria UI invece di fork di tema, uno schema normalizzato invece di codice collante, costruito per la co-scrittura tra umani e agenti AI. Costruiamo Laioutr perché i team frontend mantengano il controllo del proprio livello senza dover ricostruire il backend.