Modul-System

Das Modul-System ist das Bauprinzip, das die Service Platform erweiterbar macht. Es legt fest, wie ein Modul aussieht, wie es erkannt wird und was es zur Plattform beiträgt. Dieses Kapitel richtet sich an alle, die verstehen wollen, wie die Plattform intern zusammengesetzt ist – und wie sie wächst.

Das Prinzip

Jedes Modul beschreibt sich über einen Registrar – eine zentrale Anmeldestelle, die der Plattform mitteilt, wer das Modul ist und was es braucht. Beim Start durchsucht die Plattform die geladenen Bausteine, findet diese Registrar und bindet jedes Modul entsprechend seiner Angaben ein. Es gibt keine zentrale Liste, die von Hand gepflegt werden müsste: Ein Modul, das vorhanden ist, meldet sich selbst an.

Was ein Modul deklariert

Über seinen Registrar legt ein Modul unter anderem fest:

• Name und Pfad-Präfix – unter welchem Pfad das Modul erreichbar ist (standardmässig der kleingeschriebene Modulname, etwa /business).
• Ob es Persistenz nutzt – und unter welchem Datenbank-Schema und welchem Verbindungsnamen es seine Daten hält.
• Ob es die zentrale Identität nutzt – ob also seine Endpunkte über Zitadel abgesichert werden.
• Ob es eine eigene Konfiguration hat – ein typisierter Konfigurationsabschnitt, der aus dem Bereich ServicePlatformModules gelesen wird.
• Welche Bus-Nachrichten es verarbeitet – die Consumer für Ereignisse und Befehle vom Nachrichtenbus.
• Welche öffentlichen Endpunkte es zusätzlich anbietet – über Swagger und Health-Check hinaus.
• Welche Rollen als Administratorrollen gelten und ob Daten-Migrationen ausgeführt werden.

Aus diesen Angaben baut die Plattform den isolierten Bereich des Moduls auf: seine Dienste, seine Route, sein Schema, seine Consumer.

Isolation und gemeinsame Grundlage

Module sind voneinander getrennt, aber sie teilen dieselbe Grundlage. Jedes Modul bekommt seinen eigenen Zweig in der Anwendung, sein eigenes Datenschema und seine eigene Konfiguration. Gleichzeitig setzen alle Module auf dieselbe Infrastrukturschicht auf – Persistenz, Messaging, Migrationen, Sicherheit. Dadurch folgt jedes Modul denselben Mustern, und ein neues Modul muss die immer gleichen Grundfunktionen nicht neu erfinden.

Diese Isolation gilt auch fachlich: Was ein Modul intern tut und wie es seine Daten ablegt, ist seine Sache. Andere Module sprechen es nur über seine API oder über Ereignisse an – nie über seine Datenbank oder seinen internen Code.

Die gemeinsame Grundlage umfasst insbesondere das Entity-System: Module beschreiben ihre Daten deklarativ als Entitäten, und die Plattform leitet daraus Schema, Endpunkte, Suche, Validierung, Relationen und Audit ab. Dadurch folgt jedes Modul denselben Mustern.

Selbstbeschreibung je Modul

Jedes Modul stellt automatisch bereit:

• eine Swagger-/OpenAPI-Oberfläche unter /<modul>/swagger und das Schema unter /<modul>/swagger/v1/swagger.json,
• einen Health-Check unter /<modul>/healthcheck,
• den Eintrag in der übergreifenden Modulliste der Plattform (/modules), aus der sich Pfad, Swagger- und Health-Adresse sowie zusätzliche öffentliche Endpunkte ablesen lassen.

Genau diese Selbstbeschreibung nutzt das API Gateway, um Module automatisch erreichbar zu machen.

Warum das trägt

Das Modul-System ist der Grund, warum buzzle Commerce Core mit den Anforderungen wachsen kann, ohne unübersichtlich zu werden:

• Erweiterbarkeit – neue Fähigkeiten kommen als neues Modul hinzu, nicht als Eingriff ins Bestehende.
• Klare Verantwortung – jede Domäne hat genau ein Modul, das für sie zuständig ist.
• Unabhängige Entwicklung – an Modulen kann parallel gearbeitet werden, ohne sich in die Quere zu kommen.
• Einfacher Betrieb – trotz interner Vielfalt bleibt die Plattform ein überschaubar betreibbares Ganzes.

Welche Module buzzle Commerce Core heute mitbringt, zeigen die folgenden Kapitel – beginnend mit dem Business-Modul.