Architektur im Überblick

buzzle Commerce Core ist als Verbund eigenständiger Dienste konzipiert, die klar getrennte Aufgaben haben und über definierte Wege zusammenspielen. Diese Seite gibt den konzeptionellen Überblick; die einzelnen Bausteine werden in den folgenden Kapiteln vertieft.

Architektur auf einen Blick

Die Grafik trennt die Plattform in vier Verantwortungsbereiche. Digitale Kanäle verwenden denselben gesicherten Zugang, die Service Platform kapselt Geschäfts- und Plattformfunktionen in Modulen und die unterste Ebene verbindet Persistenz, Suche, Messaging und bestehende Systeme. Durchgezogene Pfeile stehen für synchrone Aufrufe über HTTP/REST, gestrichelte Pfeile für asynchrone fachliche Ereignisse.

Die Bausteine

Die Plattform besteht aus drei eigenständig betreibbaren Komponenten und zwei Infrastrukturdiensten:

• API Gateway – der zentrale, gesicherte Eingang. Es authentifiziert Anfragen und leitet sie an den passenden Dienst weiter. Siehe API Gateway.
• Service Platform – der modulare Backend-Layer mit den fachlichen Modulen (Business, Catalog, Order, Search, CDN, DataBridge, Reporting, Audit, Customer, Subscriptions, Procurement Gateway, Verzeichnisse). Siehe Service Platform.
• ZitadelBridge – der Vermittler zwischen der Plattform und dem Identity-Dienst. Siehe ZitadelBridge.
• Zitadel – der Identity-Provider für Login, Benutzer, Rollen und Berechtigungen. Siehe Identity mit Zitadel.
• RabbitMQ – der Nachrichtenbus für die ereignisgetriebene Kommunikation. Siehe Messaging.

Das Zusammenspiel

Ein typischer Zugriff läuft so ab: Eine Anwendung – etwa ein Kundenportal oder eine Management-Oberfläche – schickt eine Anfrage an das API Gateway. Das Gateway prüft das mitgeschickte Zugriffstoken gegen Zitadel und leitet die Anfrage anschliessend an das zuständige Modul der Service Platform weiter. Das Modul verarbeitet die Anfrage, liest oder schreibt seine Daten und antwortet über denselben Weg zurück.

Parallel dazu läuft die ereignisgetriebene Kommunikation: Löst ein Modul einen fachlich relevanten Vorgang aus – etwa das Anlegen eines Benutzers oder das Vergeben einer Rolle –, veröffentlicht es eine Nachricht auf dem Bus. Die ZitadelBridge hört auf solche Nachrichten, setzt sie in Zitadel-Aufrufe um und meldet umgekehrt Ereignisse aus Zitadel zurück an die Plattform. So bleiben die fachliche Domäne und die Identitätsverwaltung synchron, ohne direkt voneinander abhängig zu sein.

Zwei Kommunikationswege

Die Architektur nutzt bewusst zwei Wege, jeder für seinen Zweck:

• Synchron über HTTP/REST – für Abfragen und Befehle, bei denen der Aufrufer sofort eine Antwort erwartet. Dieser Weg läuft immer über das API Gateway und ist durch Zitadel abgesichert.
• Asynchron über den Nachrichtenbus – für Ereignisse und Hintergrundverarbeitung, bei denen Sender und Empfänger entkoppelt sein sollen. Dieser Weg macht die Plattform robust gegen Lastspitzen und Ausfälle einzelner Dienste, weil Nachrichten zwischengespeichert und bei Bedarf erneut zugestellt werden.

Leitprinzipien

Modularität. Jede Domäne ist ein eigenes Modul mit eigenem Datenschema und eigener API. Module werden zur Laufzeit erkannt und eingebunden, statt fest verdrahtet zu sein.

Lose Kopplung. Dienste kennen einander nicht im Detail. Sie kommunizieren über definierte Schnittstellen und über Ereignisse, nicht über gemeinsame Datenbanken oder internen Code.

Selbstbeschreibung. Jeder Dienst und jedes Modul stellt eine OpenAPI-/Swagger- Oberfläche, eine **Health-Check-**Prüfung und eine Info-Seite über die eigenen Endpunkte bereit. Die Plattform ist damit von aussen erkundbar.

Sicherheit als Fundament. Kein Modul verwaltet eigene Logins. Authentifizierung und Autorisierung laufen zentral über Zitadel und das Gateway, mit standardkonformen OAuth2-/OIDC-Verfahren.

Cloud-nativ. Alle Komponenten laufen als Container, sind zustandsarm ausgelegt und lassen sich unabhängig skalieren und aktualisieren. Konfiguration erfolgt über Umgebungsvariablen und Konfigurationsdateien.

Technologiefundament

buzzle Commerce Core basiert auf .NET 10 / C# und ASP.NET Core. Die wichtigsten Bausteine im Überblick:

• API Gateway: ASP.NET Core mit YARP (Reverse Proxy) und OAuth2-Token-Introspection.
• Service Platform: modularer ASP.NET-Core-Host; Persistenz über SQL Server (Zugriff mit Dapper, Schema-Migrationen mit FluentMigrator), Suche über Elasticsearch.
• Messaging: RabbitMQ als Transport, angesteuert über die Rebus-Bibliothek.
• Identity: Zitadel als OIDC-/OAuth2-Provider, angebunden über die ZitadelBridge.
• Betrieb: Container-Images (Docker), strukturiertes Logging (NLog), Health-Checks.

Die konkrete Ausbaustufe und die genauen Endpunkte stimmst du mit deinem Ansprechpartner bei bambit ab. Die nächsten Kapitel beschreiben die drei Kernkomponenten im Detail – beginnend mit dem API Gateway.