Enterprise Story

Login und Trust Boundaries

Stell dir den Login wie den Eingang zu einem gesicherten Büro vor. Der Benutzer weist sich zuerst beim Identity Provider aus. Danach erhält er ein Token, das an den API Gateway und später an den zuständigen Service weitergegeben wird. Jeder Übergang ist eine Trust Boundary: An jeder Grenze muss erneut geprüft werden, ob Absender, Ziel, Gültigkeit und Berechtigung stimmen.

Alltagstaugliche Ablaufbeschreibung

Dieser Abschnitt beschreibt den Ablauf ohne unnötige Fachsprache. Er dient als Brücke zwischen dem sichtbaren Ergebnis und der technischen Umsetzung.

Benutzer öffnet Login
Identity Provider prüft Identität
Token wird ausgestellt
API Gateway validiert Token
Service prüft fachliche Berechtigung
Anfrage wird verarbeitet.

Fachlicher Ablauf

Eine Person meldet sich an, damit CommerceOne ihre Identität prüfen und die erlaubten Funktionen freigeben kann. Fachlich geht es nicht nur um ein erfolgreiches Login, sondern darum, wer handeln darf, in welcher Rolle und mit welchem nachvollziehbaren Zweck.

Fachliches Ziel: Der Ablauf liefert ein fachlich eindeutiges und für Benutzer beziehungsweise Betrieb nachvollziehbares Ergebnis.
Verantwortung: Jeder beteiligte Bereich entscheidet nur innerhalb seiner eigenen fachlichen Zuständigkeit.
Sichtbares Ergebnis: Der Benutzer erhält genau den erlaubten Zugriff, ohne dass Passwortdaten durch alle Services wandern.

Technischer Ablauf

Der Client leitet die Anmeldung zum Identity Provider weiter. Nach erfolgreicher Authentication werden Tokens ausgestellt. Gateway und Resource Server prüfen Signatur, Issuer, Audience, Ablaufzeit und Scopes; die Anwendung entscheidet anschließend über die fachliche Authorization.

Daten und Schnittstellen: Daten werden an jeder Grenze validiert und nur über definierte APIs, Ports oder Events weitergegeben.
Fehlerbehandlung: Fehler werden dort behandelt, wo ausreichender Kontext und Verantwortung vorhanden sind; Wiederholungen müssen sicher und nachvollziehbar bleiben.
Technischer Nachweis: Geprüft werden Tokenvalidierung, Authorization-Entscheidung, Audit-Log und Fehlerantworten ohne sensible Details.

Zusammenspiel: Der fachliche Ablauf erklärt, warum etwas geschieht und welches Ergebnis zählt. Der technische Ablauf erklärt, wie dieses Ergebnis zuverlässig, sicher und beobachtbar umgesetzt wird.

Eine Bestellung durch das gesamte System

Diese Geschichte ist der rote Faden von V6.

Login

Die Kundin meldet sich über Keycloak an und erhält ein kurzlebiges Access Token (Access Token).

Bestellung

Das Gateway leitet die Anfrage an den Java Order Service weiter.

Transaktion

PostgreSQL speichert Bestellung und Outbox-Eintrag atomar.

Ereignis

Ein Publisher sendet OrderCreated an Kafka.

Folgeprozesse

Inventory reserviert Bestand, Payment autorisiert Zahlung, Notification informiert.

Deployment

CI und GitOps bringen eine neue Version kontrolliert nach Kubernetes.

Beobachtung

Metrics, Logs und Traces zeigen den technischen und fachlichen Zustand.

Incident

Bei steigender Latenz verbindet das Team Benutzerwirkung, Trace und Datenbankmetriken.

Recovery

Runbook, Rollback oder Restore stellen den Dienst kontrolliert wieder her.

CommerceOne: vollständiger Zusammenhang

CommerceOne ist die durchgängige Unternehmensgeschichte des Wissenssystems. Ein Kunde meldet sich an, legt eine Bestellung an, reserviert Bestand, autorisiert Zahlung und erhält eine Nachricht. Delivery, Kubernetes und Observability machen denselben Ablauf produktionsfähig.

Wie funktioniert der Ablauf?Funktionsweise

Die Story folgt einer Bestellung vom Browser über Identity, Gateway und Order Service zu PostgreSQL und Kafka. Inventory, Payment und Notification reagieren auf Events. CI/CD und GitOps liefern Änderungen aus; Kubernetes betreibt die Services; Telemetrie, SLOs und Runbooks sichern den Betrieb.

Konkretes CommerceOne-BeispielPraxis

Die Story verbindet Fachlichkeit und Technik: Ein Fehler im Login ist nicht nur ein Keycloak-Problem, sondern verhindert Umsatz. Ein wachsender Kafka Lag ist nicht nur eine Metrik, sondern verzögert Bestand und Benachrichtigung. Ein Restore ist erst erfolgreich, wenn fachlich konsistente Bestellungen wieder verfügbar sind.

Browser -> Keycloak -> Gateway -> Order Service
                         |-> PostgreSQL + Outbox
                         |-> Kafka -> Inventory / Payment / Notification
                         |-> Metrics / Logs / Traces -> Operations

So liest du das Beispiel: Identitäten und Zustände werden ausdrücklich benannt. Wiederholung, Teilfehler und Beobachtbarkeit sind Teil des Designs. Das Beispiel ist zum Lesen und Anpassen gedacht; es wird nichts automatisch ausgeführt.

Entscheidungs- und DiagnosefragenReflexion

Welches fachliche Ergebnis soll für den Benutzer entstehen?
Welche Komponente besitzt die Verantwortung und welche Daten gehören ihr?
Was passiert bei Timeout, Wiederholung oder Teilausfall?
Welches Signal beweist, dass der Ablauf korrekt funktioniert?
Welche einfachere Alternative wäre ausreichend?

Zusammenfassung: CommerceOne schafft einen roten Faden: Jede Technologie wird über ihren Beitrag zum Geschäftsergebnis, ihre Risiken und ihren Betrieb erklärt.

Die vollständige Reise einer Bestellung

Ein Kunde meldet sich über Keycloak an. Das Gateway prüft das Token und leitet die Anfrage mit Trace-ID zum Order Service. Der Service validiert Positionen, speichert Bestellung und Outbox-Ereignis in PostgreSQL und antwortet mit einer stabilen Order-ID.

Der Outbox Publisher sendet `OrderCreated` zu Kafka. Inventory reserviert Mengen, Payment autorisiert den Betrag und Notification bereitet die Bestätigung vor. Jeder Consumer verarbeitet Events idempotent. Fehler werden als fachliche Zustände oder kontrollierte Retries sichtbar, nicht als stille Datenverluste.

CI/CD baut unveränderliche Images, GitOps liefert sie auf Kubernetes aus. Metrics, Logs und Traces zeigen den Ablauf. SLOs bewerten die Benutzerwirkung. Bei einem Incident führen Runbook, Restore-Plan und Postmortem von Stabilisierung zu nachhaltiger Verbesserung. So verbindet die Story Business, Code, Plattform und Betrieb in einem einzigen nachvollziehbaren System.

Merksatz: Ein Inhalt gilt erst dann als verstanden, wenn Ziel, Ablauf, Fehlerfall und Nachweis in eigenen Worten erklärt werden können.

Was der Benutzer tatsächlich erlebt

Für den Kunden ist CommerceOne kein Verbund technischer Komponenten. Er sieht Login, Warenkorb, Bestellbestätigung und verständliche Fehlermeldungen. Deshalb werden Architekturentscheidungen immer an dieser Reise gemessen: Verhindert ein Ausfall den Abschluss? Bleibt der Status eindeutig? Kann Support den Vorgang nachvollziehen?

Warum die Geschichte wichtig ist

Die gemeinsame Story verhindert isolierte Beispiele. PostgreSQL erklärt denselben Bestellzustand, Kafka dieselben Events, Kubernetes dieselben Services und Operations dieselbe Benutzerwirkung. Dadurch werden Abhängigkeiten sichtbar und Wiederholungen in einen größeren Zusammenhang eingeordnet.

Neue Architekturgeschichten

Die vollständigen End-to-End-Abläufe findest du in der neuen Story-Sammlung.

Architekturgeschichten öffnen