Die betreibbare Systemgrenze behalten
Ein integriertes Handelssystem ist sinnvoll, wenn es das Transaktionsmodell unterstützt und das Team eine zusammenhängende Arbeitsoberfläche braucht. Composable Commerce wird interessant, wenn eine konkrete Fähigkeit unabhängig verändert werden muss und die entstehenden Integrationen verantwortlich betreut werden können. Jeder Anbietergrenze entkommen zu wollen, ist kein brauchbares Architekturziel.
Monolith bezeichnet hier eine weitgehend integrierte Anwendung, composable die Zusammenstellung von Fähigkeiten hinter definierten Schnittstellen. Das sind keine vollkommenen Gegensätze. Eine modulare Anwendung kann gemeinsam ausgeliefert werden. Mehrere eingekaufte Dienste können praktisch eng gekoppelt bleiben.
Aus Clodrons technischer Sicht zählen deshalb die Übergänge mehr als die Anzahl der Kästen im Architekturbild.
Den tatsächlichen Unabhängigkeitsbedarf benennen
Eine besondere Suche, eine spezialisierte Preislogik oder gemeinsam genutzte Produktinformationen können eine separate Komponente rechtfertigen. Überzeugender wird das Argument mit eigener Verantwortung, eigenem Änderungsrhythmus und einer Anforderung, die das bestehende System nicht erfüllt.
Weniger überzeugend ist die Trennung, wenn das integrierte System lediglich unmodern wirkt. Der Architekturvergleich von AWS erläutert gemeinsame und unabhängige Bereitstellung. Diese Unterscheidung hilft, bedeutet aber nicht, dass Composable Commerce jede Funktion zum Microservice machen muss.
Soll nur die Produktsuche verbessert werden, kann der Austausch des gesamten Handelsmotors neue Arbeit bei Zahlungen, Erstattungen und Betrieb erzeugen, ohne das ursprüngliche Problem besser zu lösen.
Einer Bestellung durch die Übergänge folgen
Ein beispielhafter Ablauf: Die Zahlung gelingt, während die Bestandsreservierung in ein Timeout läuft. Welches System entscheidet, ob eine Bestellung existiert? Wer wiederholt den Vorgang, verhindert doppelte Belastungen und zeigt dem Support den offenen Zustand?
Bei einer integrierten Plattform kann ein Teil dieser Verantwortung innerhalb derselben Produktgrenze bleiben. Zwischen getrennten Fähigkeiten muss die Integrationsschicht dagegen klare Verträge herstellen. Zuverlässige Einzeldienste ergeben nicht automatisch einen zuverlässigen Gesamtprozess.
Dasselbe gilt für Erstattungen, Teillieferungen und geänderte Kundendaten. Unser Beitrag über die betrieblichen Aufgaben im E-Commerce beschreibt, warum ein erfolgreicher Checkout noch keinen vollständigen Betrieb belegt. Die Beispiele sind Prüfanforderungen, keine Fehlerbehauptungen über bestimmte Anbieter.
Koordination in die Kosten aufnehmen
Ein composable Angebot muss die führenden Systeme für Produkte, Preise, Bestellungen und Kunden benennen. Ereignisverarbeitung, Abgleich, Überwachung, Zugänge und Supporteskalation gehören dazu. Verweisen alle Anbieter aufeinander, muss trotzdem jemand den Kundenprozess wiederherstellen.
Auch ein integriertes Angebot braucht Prüfung. Wie werden Erweiterungen gepflegt? Welche Daten lassen sich exportieren? Welche Geschäftsregeln verlangen Umwege? Einfachheit darf keinen nachweislich schädlichen Engpass rechtfertigen.
Unsere E-Commerce-Entwicklung kann beide Ansätze unterstützen. Die Aufgabe ist ein schlüssiges System, nicht ein Architekturbegriff als Reifezeichen.
Diese Woche eine begrenzte Trennung testen
Zunächst werden blockierte Fähigkeit, geschäftliche Folge und verantwortliche Person festgehalten. Vor der Produktauswahl stehen Ein- und Ausgaben fest. Veraltete Daten, wiederholte Nachrichten und eine unerreichbare Abhängigkeit gehören in die Abnahmeszenarien.
Bleibt kein bedeutsamer Engpass übrig, sollte das integrierte System verbessert werden. Ist die Grenze real, wird die kleinste passende Trennung prototypisch umgesetzt und ihr Fehlerfall mit dem Betrieb durchgespielt. Erst klare Verantwortung rechtfertigt die Erweiterung.