Der Ausgangspunkt.
Die Domäne umfasste Archivierungssitzungen, Typen, Organisationscodes, Input- und Output-Storage, Quell- und Ergebnispakete sowie den Workflow-Lebenszyklus. Mitarbeitende brauchten einen praktischen Weg, um diese zusammenhängenden Datensätze zu verstehen.
Die Funktion musste in einer grösseren single-spa-Plattform leben, die bereits Header, Footer, Navigation und wiederverwendbare Microfrontends bereitstellte. Diese Komponenten wiederzuverwenden war ein Hauptziel, keine spätere optische Bereinigung.
Eine eigenständige React-Anwendung hätte die Plattform-Shell dupliziert und einen zweiten Wartungsort für Navigation und Chrome geschaffen. Die nützliche Grenze war eine fokussierte Archivierungserfahrung, welche die bestehende Plattform komponieren konnte.
Was das Design lösen musste.
Die nützliche Grenze lag zwischen Prozessstatus, Benutzeraktion und Host-Plattform:
- Sitzung, Quellpakete und Output mussten über neun Prozessschritte verständlich bleiben.
- Benutzeraktionen mussten sauber auf gültige Prozessübergänge abgebildet werden.
- Die neue Oberfläche musste Header, Footer, Navigation und bestehende Komponentenkonventionen wiederverwenden, statt eine parallele Shell auszuliefern.
- Das React-single-spa-Microfrontend brauchte einen engen Mount-Punkt und Integrationsvertrag, damit Archivierungsregeln nicht in den Host durchsickerten.
- Backend-Regeln, Camunda-Status und Frontend-Aktionen durften nicht zu verschiedenen Interpretationen desselben Workflows werden.
Die Diagnose.
Camunda konnte den Prozess koordinieren, aber Orchestrierung allein war noch keine brauchbare Arbeitsoberfläche. Es fehlte eine zusammenhängende Anwendungsgrenze um den Workflow.
Die Host-Plattform hatte Komposition und Chrome bereits gelöst. Diese Teile neu zu bauen, hätte mehr Code erzeugt, ohne den Archivierungsworkflow zu verbessern. Deshalb beschränkte ich das Microfrontend auf die fehlende Domänenoberfläche.
Ich trennte die Verantwortung bewusst: Der Host behält Navigation und gemeinsame Komponenten; Spring Boot besitzt Anwendungsregeln, S3-kompatible Storage-Referenzen und Camunda-Integration; das React-single-spa-Microfrontend zeigt aktuellen Status und gültige Aktionen.
Der resultierende Anwendungsausschnitt.
Die bestehende single-spa-Shell bindet das React-Microfrontend in gemeinsamen Header, Footer und Navigation ein. Das Microfrontend liefert nur die Archivierungsoberfläche. Ein fokussierter Spring-Dienst übersetzt Aktionen in Workflow-Operationen und Storage-Referenzen, während Camunda den Prozess von der Sitzungserstellung bis zum Output-Tracking koordiniert.
Warum diese Grenzen zur Host-Plattform passten.
Dies war keine Greenfield-Auswahl des Stacks. Shell, Workflow-Engine und Storage-Konventionen gehörten zu einer bestehenden Plattform; die Aufgabe war, eine zusammenhängende Fähigkeit hinzuzufügen, ohne diese Grenzen zu duplizieren oder zu umgehen.
Ein fokussierter Spring-Boot-Dienst als Anwendungsgrenze
- Warum
- Der Dienst bündelte die Zuständigkeit für Anwendungsregeln, gültige Aktionen, Camunda-Integration und Storage-Referenzen im Backend. React konnte ein Anwendungsmodell nutzen, ohne die Mechanik der Prozess-Engine zu kennen.
- Was ich ausgeschlossen habe
- Direkte Camunda-Aufrufe aus dem Browser oder verteilte Archivierungsregeln in gemeinsamen Diensten hätten Orchestrierungsdetails offengelegt und mehrere Auslegungen des gültigen Workflow-Verhaltens geschaffen.
- Der Preis dafür
- Die zusätzliche API- und Abbildungsschicht muss sich mit dem Prozess weiterentwickeln; Fehler an der Grenze zwischen Dienst und Engine brauchen eine ausdrückliche Behandlung.
Camunda für den neunstufigen Prozess
- Warum
- Camunda koordinierte den Workflow bereits. Die Übergänge dort zu belassen, erhielt eine einzige Quelle für den Fortschritt, während der Dienst diesen Status für Mitarbeitende übersetzte.
- Was ich ausgeschlossen habe
- Eine eigene Zustandsmaschine, besonders wenn sie hauptsächlich als UI-Status abgebildet wäre, hätte Prozesslogik dupliziert und den Browser mit der Workflow-Engine um die Autorität konkurrieren lassen.
- Der Preis dafür
- Prozessdefinition und Anwendungsmodell müssen aufeinander abgestimmt bleiben; die Betriebsdiagnose führt sowohl durch den Dienst als auch durch die Engine.
React in der bestehenden single-spa-Komposition
- Warum
- Ein klar begrenztes Microfrontend konnte Header, Footer, Navigation und Plattformkonventionen wiederverwenden und nur die Archivierungsroute samt Interaktionsmodell besitzen.
- Was ich ausgeschlossen habe
- Eine neue Shell oder eine eigenständige React-Anwendung hätte das Vorhaben über die fehlende Fähigkeit hinaus erweitert und doppelte Navigation sowie doppelten Chrome geschaffen.
- Der Preis dafür
- Das Microfrontend hängt von einem stabilen Mount- und Integrationsvertrag ab; Änderungen der gemeinsamen Plattform erfordern Koordination statt vollständiger lokaler Kontrolle.
S3-kompatibler Storage für Input- und Output-Pakete
- Warum
- Paketinhalte blieben an einer Object-Storage-Grenze, auf die Dienst und Workflow verwiesen. So blieben Archivierungsdatensätze und Verantwortung für binäre Inhalte getrennt.
- Was ich ausgeschlossen habe
- Datenbank-Blobs hätten Paketinhalt an den Lebenszyklus relationaler Daten gebunden; lokale Dateien hätten ihn an eine bestimmte Dienstinstanz und deren Deploymentweg gebunden.
- Der Preis dafür
- Buckets, Endpunkte, Zugangsdaten und fehlende Objekte werden zu ausdrücklichen Betriebsbelangen, die der Dienst nachvollziehbar darstellen muss.
Betriebsregeln für einen bedienbaren Workflow.
Die Architektur liefert eine Quelle der Prozesswahrheit; diese Regeln machen daraus eine Erfahrung, die Mitarbeitende lesen, ihr vertrauen und nach einem Problem fortsetzen können.
Status vor der Aktion zeigen
Die aktuelle Sitzung, ihre Quell- und Ergebnispakete sowie die Prozessphase bleiben sichtbar, bevor Mitarbeitende den nächsten Schritt wählen. Eine Aktion ohne diesen Kontext wird nicht als Fortschritt dargestellt.
Der ZielkonfliktDie Oberfläche muss nicht verfügbare, laufende und fehlgeschlagene Zustände erklären, statt nur den Idealfall zu optimieren.
Gültige Aktionen aus dem Backend-Status ableiten
Die Oberfläche zeigt Übergänge, die das Anwendungsmodell unterstützt, während der Dienst ungültige ablehnt. Lokaler Browser-Status wird nie zu einer zweiten Autorität über den nächsten Schritt.
Der ZielkonfliktStatusaustausch und Aktualisierung müssen ausdrücklich behandelt werden, doch eine veraltete Ansicht kann keinen gültigen Workflow-Schritt erfinden.
Kontinuität von Sitzung und Paketen bewahren
Sitzung, Quellpakete und Ergebnispakete bleiben über den neunstufigen Weg verbunden. Die Prüfung folgt derselben Reise von Erstellung und Zuordnung über die Verarbeitung bis zur Nachverfolgung der Ausgabe.
Der ZielkonfliktModell und Oberfläche tragen mehr Kontext als eine reine Aufgabenansicht, doch Mitarbeitende können den Zusammenhang zwischen Arbeit und Ergebnis verfolgen.
Fehler und Wiederholung sichtbar machen
Ein unvollständiger, laufender oder fehlgeschlagener Schritt bleibt sichtbar. Erlaubt die nächste gültige Aktion einen neuen Versuch oder die Fortsetzung, erscheint sie erst nach Bestätigung durch das Backend.
Der ZielkonfliktDie Oberfläche muss mehr Zustände und Fehlerwege erklären, trennt dafür aber Warten, Fehlschlag und Wiederaufnahme, statt Mitarbeitende raten zu lassen.
Delivery und Prüfung.
Die Prüfung folgt den neun Schritten: Sitzung erstellen, Quellpakete verbinden, Workflow starten, gültige Übergänge beobachten und Ergebnispakete verfolgen.
Ich prüfte auch die Kompositionsgrenze: Die neue Route musste in bestehendem Header, Footer und Navigation leben, ohne eine zweite Shell einzuführen oder Archivierungsstatus in gemeinsame Plattformkomponenten zu schieben.
Die anderen wichtigen Fehlerfälle liegen an den Grenzen. Der Dienst muss ungültige Übergänge ablehnen, die UI unvollständige oder laufende Zustände ehrlich zeigen, und die Prozessintegration muss die Quelle des Workflow-Status bleiben.
Das qualitative Ergebnis.
Der Anwendungsausschnitt deckt Sitzungsverwaltung, Paketverarbeitung und Workflow-Steuerung von der Oberfläche bis zum Camunda-Prozess ab.
Mitarbeitende haben einen Ort, an dem sie die Arbeit verstehen und voranbringen können. Die Plattform behält Header, Footer, Navigation und bekannte visuelle Konventionen.
Die Plattform erhält eine gekapselte Fähigkeit statt einer parallelen Anwendung: keine doppelte Shell, kein zweites Navigationsmodell und keine über fremde Microfrontends verteilten Archivierungsregeln.
Organisation, Produkt, interne Typen, Endpunkte, Buckets, Zugangsdaten und Liefertermine sind weggelassen. Der fachliche Lebenszyklus stammt aus der Projektdokumentation.