Service Platform

Die Service Platform ist das Herz von buzzle Commerce Core – der Backend-Layer, in dem die eigentliche Commerce-Logik lebt. bambit bezeichnet sie als Digital Commerce Services Layer. Sie ist kein einzelner, monolithischer Dienst, sondern ein Host, der fachliche Module lädt und jedes von ihnen als eigenständige, in sich geschlossene Einheit betreibt.

Ein Host, viele Module

Beim Start durchsucht die Plattform die vorhandenen Module und bindet jedes davon unter einem eigenen Pfad-Präfix ein. Ein Modul für Bestellungen wird so unter /order erreichbar, das Business-Modul unter /business, die Suche unter /search und so weiter. Jedes Modul erhält seinen eigenen isolierten Bereich innerhalb des Hosts – mit eigener Dienstregistrierung, eigener Pipeline und eigener Konfiguration.

Diese Architektur verbindet zwei Welten: Sie ist so einfach zu betreiben wie ein einzelner Dienst (ein Prozess, ein Deployment), aber intern so klar getrennt wie ein Verbund von Microservices. Neue fachliche Fähigkeiten kommen als neues Modul hinzu, ohne dass bestehende Module angefasst werden müssen.

Was jedes Modul mitbringt

Ein Modul ist mehr als ein Stück Code – es ist eine vollständige fachliche Einheit. Je nach Bedarf bringt ein Modul mit:

• eine eigene REST-API unter seinem Pfad-Präfix,
• ein eigenes Datenbank-Schema in SQL Server, getrennt von anderen Modulen,
• eigene Bus-Consumer, die auf Ereignisse und Befehle reagieren,
• eine **eigene Swagger-/OpenAPI-**Dokumentation unter /<modul>/swagger,
• einen eigenen Health-Check unter /<modul>/healthcheck,
• eine eigene Konfiguration, sauber vom Rest getrennt.

Die Details dieses Baukastens – Erkennung, Registrierung, Pfade, Schemata – beschreibt das Kapitel Modul-System.

Selbstbeschreibung und Info-Seiten

Die Plattform ist von aussen erkundbar. Neben den modul-eigenen Swagger-Oberflächen stellt der Host mehrere übergreifende Endpunkte bereit:

• Eine Info-Seite (die Wurzeladresse) listet alle geladenen Module mit ihren Pfaden, Swagger- und Health-Check-Adressen sowie die Plattform- und Umgebungsinformationen auf.
• /modules liefert dieselbe Modulliste maschinenlesbar als JSON – genau diesen Endpunkt nutzt das API Gateway für seine Modul-Discovery.
• /llms.txt gibt eine kompakte, für KI-Werkzeuge lesbare Beschreibung der Plattform aus.

Persistenz und Datenhaltung

Die Module speichern ihre strukturierten Daten in SQL Server. Der Zugriff erfolgt schlank über Dapper, Schema-Änderungen werden versioniert über FluentMigrator ausgerollt. Jedes Modul arbeitet in seinem eigenen Datenbank-Schema, sodass sich die Domänen auch auf Datenebene nicht ins Gehege kommen.

Das Search-Modul ergänzt diese relationale Haltung um einen Elasticsearch-Index für schnelle Suche, und das Audit-Modul um einen append-only-Verlauf für die lückenlose Nachvollziehbarkeit.

Kommunikation nach aussen und innen

Nach aussen sprechen die Module REST und werden über das API Gateway erreichbar. Nach innen und untereinander kommunizieren sie zusätzlich ereignisgetrieben über den Nachrichtenbus. Ein Modul kann Ereignisse veröffentlichen (etwa „Rolle wurde vergeben”) und auf Ereignisse oder Befehle anderer Teilnehmer reagieren – ohne die anderen Module direkt zu kennen.

Sicherheit

Die Module verwalten keine eigenen Logins. Wo ein Modul geschützte Funktionen anbietet, stützt es sich auf die zentrale Identität aus Zitadel und die vom Gateway durchgesetzte Authentifizierung. Rollen und Berechtigungen werden über standardisierte Claims ausgewertet.

Technologie

Die Service Platform basiert auf .NET 10 / ASP.NET Core und läuft als Container. Die zentrale Infrastruktur – Persistenz, Messaging, Migrationen, Konfiguration, Sicherheit – ist in einer gemeinsamen Infrastrukturschicht gebündelt, auf der alle Module aufsetzen. Dadurch folgt jedes Modul denselben Mustern, und neue Module fügen sich ohne Reibung ein.