MACH Architecture Ecommerce: Wie die 4 Layer wirklich integrieren

Eine MACH Architecture im E-Commerce besteht aus vier Verantwortungs-Layern: einem Frontend-Layer, der die Storefront rendert, einem Commerce-Backend, das Katalog, Preise und Carts hält, einem Omnichannel-/Order-Management-System (OMS), das Bestellungen kanalübergreifend orchestriert, und einem Discovery-Layer für Search, Recommendations und Merchandising. Sauber wird die Architektur nicht dadurch, dass jeder Layer austauschbar ist, sondern dadurch, dass die Verträge zwischen den Layern explizit sind: Wer ruft wen, über welche API, mit welchem Datenmodell. Genau da entscheidet sich, ob aus vier Microservices ein funktionierender Stack wird oder ein Integrations-Knäuel mit fünf Glue-Code-Schichten.

Dieser Beitrag verdrahtet die vier Layer an einem konkreten DACH-tauglichen Stack: Frontend mit Laioutr, Backend mit Emporix, Omnichannel-OS mit Nekom, Discovery mit BatteryIncluded. Kein generisches "Was ist Composable", sondern die Frage, welche Contracts an den vier Schnittstellen laufen.

Layer 1 - Frontend: Laioutr als Frontend Management Platform

Der Frontend-Layer ist der einzige Layer, den dein Kunde direkt sieht, und der Layer, der am häufigsten neu gebaut wird, wenn das Backend wechselt. Laioutr ist hier nicht ein weiterer Visual Builder, sondern eine Frontend Management Platform (FMP) - die Kategorie, die wir mit dem Begriff (Laioutr-coined) selbst definieren. Die ausgelieferte Storefront ist eine echte Nuxt-App mit SSR und Edge-Delivery, kein generierter HTML-Output aus einem Builder-DSL.

Der entscheidende Integrationspunkt sitzt eine Ebene tiefer: Orchestr, der Unified Data Layer. Orchestr normalisiert Produkt-, Bestands-, Kategorie- und Order-Daten aus dem jeweiligen Backend in ein einheitliches, GraphQL-konsumierbares Schema. Die Frontend-Komponenten sprechen dieses eine Schema an, nicht die rohe Backend-API. Das ist der Grund, warum ein Backend-Wechsel kein Frontend-Rewrite ist: Der Vertrag, den die Komponente kennt, bleibt stabil, auch wenn dahinter Emporix gegen ein anderes Backend getauscht wird.

Wenn du den Layer im Detail sehen willst, lohnt der Composable Headless Frontend-Hub als Einstieg in die Nuxt-Foundation und den Orchestr-Layer.

Layer 2 - Backend: Emporix als Commerce-Engine

Emporix liefert die Commerce-Domäne: Catalog, Pricing, Cart, Checkout-Logik, B2B-Strukturen. Als API-First-Backend ist Emporix nicht für ein bestimmtes Frontend gebaut, sondern stellt seine Domäne als Services bereit. Das ist die Voraussetzung für die Verdrahtung mit Laioutr.

Der Contract Frontend zu Backend: Orchestr betreibt einen Emporix-Connector, der die Emporix-REST-/Catalog-APIs auf das interne Orchestr-Schema mappt. Heißt konkret: Produktabfragen, Preisermittlung und Cart-Mutationen laufen über den Connector, nicht über handgeschriebenen Glue-Code in der Storefront. Die Frontend-Komponente fragt product, price, cart im Orchestr-Schema an, der Connector übersetzt das in Emporix-Calls und die Emporix-Antwort zurück ins normalisierte Modell. Custom-Felder aus Emporix, die kein Standard-Mapping haben, werden über einen GraphQL-Fallback durchgereicht, statt das Schema zu brechen.

Diese Connector-Mechanik ist Pillar-2-Substanz: Die dedizierte Headless Frontend für Emporix-Page beschreibt das Mapping und die unterstützten Entitäten im Detail.

Layer 3 - Omnichannel-OS: Nekom für Order-Orchestrierung

Sobald Bestellungen aus mehr als einem Kanal kommen - Web-Storefront, POS, Marketplace, Telefon - braucht der Stack einen Layer, der Orders kanalübergreifend einsammelt, routet und gegen Inventory abgleicht. Nekom übernimmt dieses Order Management und die Omnichannel-Orchestrierung: Bestandsverfügbarkeit über Lager und Filialen, Order-Routing, Retouren, Fulfillment-Status.

Der Contract Backend/Frontend zu OMS läuft an zwei Stellen. Erstens beim Checkout: Wenn eine Order in der Storefront (Laioutr Checkout) oder in Emporix entsteht, wird sie an Nekom als orchestrierende Instanz übergeben - üblicherweise über ein Order-Event oder einen Order-Create-Call. Zweitens beim Verfügbarkeits-Read: Die Storefront soll die reale, kanalübergreifende Verfügbarkeit anzeigen, nicht nur den Lagerstand eines einzelnen Backends. Hier liest Orchestr den Inventory-/Availability-Endpunkt von Nekom und reicht ihn als Feld im normalisierten Produkt-Schema an die Komponente weiter. Die klare Regel: Emporix bleibt Source of Truth für Catalog und Pricing, Nekom wird Source of Truth für Availability und Order-Status. Wer das nicht trennt, baut sich doppelte Bestandswahrheiten ein.

Layer 4 - Discovery: BatteryIncluded für Search und Recommendations

Discovery ist der Layer, der entscheidet, was der Kunde überhaupt findet: Search, Autocomplete, Recommendations, Merchandising-Regeln. BatteryIncluded indexiert den Katalog und liefert relevanzsortierte Ergebnisse plus Empfehlungs-Slots zurück.

Der Contract Discovery zu Frontend ist bewusst entkoppelt vom Catalog-Read. Discovery braucht einen aktuellen Index, also fließt der Emporix-Katalog (samt Nekom-Availability für Out-of-Stock-Filterung) in BatteryIncluded - entweder per Feed-Sync oder eventgetrieben bei Katalog-Änderungen. Im Frontend ruft die Such-/Listing-Komponente dann nicht Emporix, sondern den BatteryIncluded-Such-Endpunkt auf. Über den Laioutr App Store wird dieser Discovery-Provider per Click-to-Connect angebunden, statt pro Integration einen Engineering-Sprint zu fahren. Das Ergebnis: Suche und Produktlisten laufen über den spezialisierten Discovery-Layer, Produktdetails und Cart über den Catalog-Layer, und beide bleiben unabhängig skalierbar.

Wie die vier Contracts zusammenspielen

In Summe ergeben sich vier explizite Verträge, die durch Orchestr als Frontend-seitiger Vermittler laufen:

1. Frontend zu Backend (Catalog/Cart): Orchestr-Schema gegen Emporix-Connector.
2. Frontend/Backend zu OMS (Order/Availability): Order-Event an Nekom, Availability-Read aus Nekom ins Orchestr-Schema.
3. Catalog zu Discovery (Index): Emporix-Katalog plus Nekom-Availability als Feed in BatteryIncluded.
4. Discovery zu Frontend (Search): Such-/Recommendation-Calls gegen BatteryIncluded, angebunden via App Store.

Der Punkt ist nicht, dass alles miteinander redet, sondern dass jeder Layer eine klare Quelle der Wahrheit hat und die Storefront nur ein normalisiertes Schema kennt. Wer den Frontend-Layer als orchestrierende Ebene begreift, hält die Architektur-Entscheidungen reversibel - Backend, OMS oder Discovery lassen sich später tauschen, ohne die Komponenten anzufassen. Mehr zum Frontend-Layer als Composable-Baustein im Composable Digital Experience Platform-Hub.

Was du gewinnst: Verdrahtet vs. Glue-Code-Knäuel

• Aspekt | Direkt verdrahtet (Glue-Code pro Layer) | Über Frontend-Orchestr-Layer
• Backend-Wechsel | Frontend-Rewrite, jede Komponente betroffen | Connector tauschen, Schema bleibt stabil
• Availability-Quelle | uneinheitlich, oft doppelte Bestandswahrheiten | Nekom als Single Source of Truth, ein Feld im Schema
• Discovery-Anbindung | Custom-Integration-Sprint pro Provider | Click-to-Connect über App Store
• Datenmodell im Frontend | n rohe Backend-APIs | ein normalisiertes GraphQL-Schema
• Performance-Verantwortung | pro Layer einzeln zu tunen | Core Web Vitals als Plattform-Eigenschaft

Die Performance-Zeile ist kein Nebenpunkt: Wenn der Frontend-Layer die Daten-Aggregation übernimmt, kann er auch das Rendering-Budget kontrollieren. Wie Laioutr Core Web Vitals als Architektur-Eigenschaft statt als Quartalsend-Optimierung behandelt, steht auf der Performance und Core Web Vitals-Produkt-Page.

FAQ

Brauche ich für eine MACH Architecture zwingend alle vier Layer separat? Nein. Du brauchst saubere Contracts an den Stellen, wo Verantwortung wechselt. Ein kleinerer Stack kann Catalog und Discovery zusammen halten. Sobald Search-Relevanz, kanalübergreifendes OMS oder ein Backend-Wechsel real werden, zahlt sich die Layer-Trennung aus.

Warum sitzt die Orchestrierung im Frontend-Layer und nicht im Backend? Weil der Frontend-Layer am häufigsten iteriert und am häufigsten neu gebaut wird. Wenn die Normalisierung dort sitzt, bleibt das Datenmodell der Komponenten stabil, während Backend, OMS und Discovery dahinter austauschbar sind.

Was passiert mit Custom-Feldern, die kein Standard-Mapping haben? Sie laufen über einen GraphQL-Fallback durch den Connector, statt das normalisierte Schema zu brechen. Standard-Entitäten werden gemappt, Spezialfälle bleiben durchreichbar.

Nächster Schritt

Wenn du einen Composable Stack im DACH-Markt planst oder einen bestehenden entkoppeln willst: Wir zeigen dir die 4-Layer-Verdrahtung an deinem konkreten Backend. Buch ein technisches Architektur-Gespräch über die Composable Headless Frontend-Page, oder lies parallel, wie wir typische Verdrahtungs-Fehler und FMP-Patterns korrigieren, in unserem Insights-Beitrag Composable Stack Correction: Engineering-Patterns für FMP.

Über den Autor: Sebastian ist Mitgründer und CTO von Laioutr und verantwortet die technische Voice. Sein Standpunkt: Performance und Component-Disziplin sind Architektur-Eigenschaften, keine nachgelagerten Optimierungen - eine UI-Library statt Theme-Forks, ein normalisiertes Schema statt Glue-Code, gebaut für Co-Authoring von Mensch und KI-Agent. Wir bauen Laioutr, damit Frontend-Teams die Kontrolle über ihren Layer behalten, ohne das Backend neu zu bauen.