Composable Commerce Tauschen Sie Teile. Nicht den ganzen Shop.

Composable Commerce heißt: Suche, PIM, CMS oder Preislogik laufen als eigene Dienste und sind über Schnittstellen verbunden. Wir lösen sie einzeln aus Ihrem bestehenden Shop heraus, dort wo es sich lohnt, und lassen den Rest weiterlaufen.

Architektur besprechen

Wann es sich lohnt

Nicht jeder Monolith muss zerlegt werden.

Lohnt sich, wenn

  • ein Teil des Shops ständig bremst, etwa die Suche oder die Produktpflege,
  • mehrere Teams unabhängig voneinander ausliefern sollen,
  • Sie einen Baustein austauschen wollen, ohne den Rest anzufassen.

Eher nicht, wenn

  • Ihr Shop stabil läuft und sich selten etwas ändert,
  • niemand da ist, der fünf Dienste statt einem betreibt.

Monolith? Macht sich gut im Museum.

Wir lösen einen Baustein nach dem anderen heraus. Der Shop läuft währenddessen weiter.

Architektur besprechen
Betonklotz neben bunten Holzbausteinen

Typischer Aufbau

Vier Schichten. Welche Produkte, entscheiden Sie.

  • Oberfläche

    Headless-Frontend oder PWA, CMS, Suche, Personalisierung.

  • Fachdienste

    Warenkorb und Checkout, Preise und Aktionen, Katalog und PIM, Bestellungen.

  • Daten

    Ereignisse zwischen den Diensten, Data Warehouse, KI-Dienste.

  • Infrastruktur

    API-Gateway, Zugriffsrechte, Caching am Rand, Monitoring über alle Dienste.

Magento kann dabei einer der Dienste bleiben, zum Beispiel für Preise, Kunden und Bestellungen.

Verbindungen

Entkoppeln ist leicht. Zuverlässig verbinden ist die Arbeit.

  • Ereignisse statt Direktaufrufe

    Ändert sich ein Preis im ERP, erfährt der Shop es über ein Ereignis. Fällt ein Dienst kurz aus, geht nichts verloren.

  • Abläufe mit Wiederholung

    Bestellungen, Freigaben und Retouren laufen als Workflows mit Zeitlimits, Wiederholungen und manuellen Schritten, wo nötig.

  • Ein Eingang für das Frontend

    Ein API-Gateway übernimmt Anmeldung und Begrenzung und liefert jedem Kanal die Antwort, die er braucht.

  • Verträge zwischen Diensten

    Jede Schnittstelle ist beschrieben und getestet. Ein Update in Dienst A bricht Dienst B nicht unbemerkt.

Betrieb

Ohne klare Zuständigkeit wird aus Modularität Chaos.

  1. Ein Besitzer pro Dienst

    Mit Betriebsanleitung und Eskalationsweg. Kein „das macht niemand“.

  2. Vertragstests

    Laufen bei jedem Release und zeigen, ob eine Änderung einen anderen Dienst trifft.

  3. Sicher zurückrollen

    Feature Flags und schrittweise Releases, damit ein Fehler nur einen Teil der Nutzer trifft.

  4. Budgets pro Schnittstelle

    Antwortzeit und Kosten haben eine Grenze. Wird sie überschritten, meldet sich das Monitoring.

Häufige Fragen

Was Teams vorher wissen wollen.

Was ist der Unterschied zum Monolithen?
Ein Monolith bündelt Katalog, Checkout, Suche und CMS in einer Software. Bei Composable übernimmt jeder Dienst eine Aufgabe und spricht über Schnittstellen mit den anderen. So lässt sich ein Teil austauschen oder skalieren, ohne den Rest anzufassen.
Müssen wir den Shop komplett neu bauen?
Nein. Meist fängt es mit einem einzelnen Dienst an, zum Beispiel der Suche oder dem PIM. Der Rest des Shops läuft weiter, während der neue Dienst schrittweise übernimmt.
Ab wann lohnt sich das?
Wenn mehrere Teams am Shop arbeiten und sich gegenseitig blockieren, oder wenn ein einzelner Teil des Systems den Rest ausbremst. Für einen kleinen, stabilen Shop ist es meist zu viel.
Wie lange dauert der Umbau?
Das hängt davon ab, welchen Dienst Sie zuerst herauslösen und wie viel daran hängt. Eine belastbare Schätzung geben wir nach einem Blick auf Ihren Shop und Ihre Schnittstellen, nicht vorher.
Was kostet das?
Die Hauptkosten liegen in der Integration und im Betrieb mehrerer Dienste, nicht in Lizenzen. Deshalb empfehlen wir, mit einem begrenzten ersten Baustein anzufangen.

Welcher Baustein bremst Sie? Mit dem fangen wir an.

Composable-Roadmap planen