meldestelle/docs/01_Architecture/adr/0028-plan-b-email-based-online-nennung.md

ADR 0028: Plan-B - Fallback auf E-Mail-basierte Online-Nennung (MVP)

Status: Angenommen Datum: 2026-04-22 Entscheider: Lead Architect, Product Owner

Kontext

Ursprünglich war geplant, dass die Desktop-App vollständig integriert mit dem ZNS die Konfiguration von Turnieren ermöglicht. Daraus sollten automatisch Web-Formulare für die Online-Nennung generiert werden. Die Entwicklung dieser komplexen End-to-End-Strecke inklusive ZNS-Synchronisation und Formular-Generierung ist zeitlich in Verzug geraten. Das Kernziel – die rechtzeitige Bereitstellung einer funktionierenden Online-Nennung für Teilnehmer – ist gefährdet.

Gleichzeitig haben Tests ergeben, dass der aktuelle Mailserver (World4You) das sogenannte "Plus-Addressing" (z.B. online-nennen+26128@...) nativ nicht unterstützt (Fehler: 550 Unknown User), weshalb ein robusterer Mechanismus für das Mail-Routing pro Turnier gefunden werden muss.

Entscheidung

Wir setzen das Prinzip der Graceful Degradation an und wechseln für das Online-Nenn-System auf einen pragmatischen MVP (Plan-B):

1. Entkopplung: Die Web-App wird vorerst nicht dynamisch aus der Desktop-App/ZNS-Datenstruktur generiert.
2. Statische Frontend-Formulare: Wir erstellen einfache, statische (oder semi-statische) Nenn-Formulare im Web (WasmJs) mit grundlegender clientseitiger Validierung (Pflichtfelder).
3. E-Mail als Integrationsschicht: Das Backend dient lediglich als "Form-to-Email-Gateway". Wenn ein Teilnehmer das Formular absendet (POST Request mit JSON-Payload), generiert das Backend eine strukturierte E-Mail.
4. Catch-All Routing statt Plus-Addressing: Aufgrund der Limitationen des Hosters nutzen wir kein Plus-Addressing. Stattdessen wird eine Subdomain (*.turniere.mo-code.at) mit einem Catch-All-Postfach eingerichtet. Die Web-App sendet als Empfängeradresse das Format t-<turniernummer>@turniere.mo-code.at (z.B. t-26128@turniere.mo-code.at).

Konsequenzen

Positiv

• Time-to-Market: Die Kernanforderung (Nennungen empfangen) kann extrem schnell umgesetzt und deployt werden.
• Stabilität: Das System ist hochgradig ausfallsicher. Es gibt keine komplexe DB-Synchronisation, die im Live-Betrieb abbrechen könnte.
• Kein Blocker für Desktop-App: Das Team kann ungestört weiter an der komplexen Desktop-ZNS-Integration arbeiten, während das Nenn-Problem für die User gelöst ist.
• Klar definierter Mail-Filter: Durch das Catch-All können Nennungen im Postfach sauber nach der Empfängeradresse (To: t-26128@...) den Turnieren zugeordnet werden.

Negativ

• Manueller Aufwand im Backoffice: Nennungen kommen vorerst als E-Mails (Text/HTML) an und müssen (bis zu einer späteren Automatisierung) manuell oder per Skript aus dem Postfach ins eigentliche System übertragen werden.
• Kein automatisiertes Setup: Formulare müssen bei Bedarf per Hand im Frontend-Code oder einer einfachen Konfigurationsdatei angepasst werden.
• Infrastruktur-Abhängigkeit: Erfordert einmalige Konfiguration der Subdomain und des Catch-Alls beim Hoster.

Nächste Schritte

1. enableWasm=true in gradle.properties aktivieren (erledigt).
2. Einrichtung der Subdomain und des Catch-All-Postfachs bei World4You klären.
3. Web-App (Frontend) mit einem minimalen "Hallo Du!"-Formular implementieren.
4. Backend-Endpoint (POST to Mail) implementieren und SMTP anbinden.
5. End-to-End-Test auf dem Staging/Prod-Server (Gitea Pipeline).