docs(c4): migrate architecture diagrams to draw.io and refine container/workflow visualizations
- Replaced outdated `.puml` and `.mermaid` diagrams with modernized `.drawio` versions for enhanced clarity. - Added `container_diagram.drawio` to depict offline-first architecture and backend synchronization workflow. - Introduced `workflow_turnieranlage.drawio` to visualize the tournament creation process (3-step wizard). - Archived legacy diagrams under `docs/01_Architecture/_archive` for reference.
This commit is contained in:
@@ -1592,7 +1592,74 @@ Wie machen wir weiter?
|
||||
Damit sind Veranstaltung, Turnier und Bewerb architektonisch sauber aufgebaut.
|
||||
Wollen wir uns nun dem nächsten großen Meilenstein widmen: Den Nennungen (Datenschutzkonformes Web-Formular für lizenzfreie Starter vs. n2-xxxxx.dat Import vom ZNS) sowie der Frage, wie Teilnehmer und ihre Pferde sicher in unsere Bewerbe gebucht und abgerechnet werden?
|
||||
|
||||
|
||||
---
|
||||
Ich
|
||||
---
|
||||
|
||||
Wollen wir nicht zuvor die Desktop-App soweit bekommen, dass wir in der Lage sind:
|
||||
- Eine oder mehrere Veranstaltungen anzulegen
|
||||
- Zu den jeweiligen Veranstaltungen ein oder mehr Turniere anzulegen
|
||||
- Den gesammten Prozess Turnier-anlegen
|
||||
- Zum Turnier Prüfungen/Bewerbe anlegen
|
||||
- usw.
|
||||
Wir müssen den Prozess genauer denfinieren und die Workflows in kleine hädelbare Einheiten bestimmen, damit wir diese Spartenspezifisch und wartbar entwickeln können. Jetzt und in Zukunft.
|
||||
In
|
||||
docs/01_Architecture/c4
|
||||
haben wir schon einige Diagramme/Grafiken zum visualisieren.
|
||||
Kannst du dir diese einmal genauer unter die Lupe nehmen und diese analysiere, korrigieren bzw. vervollständigen, optimieren und aktualisieren?
|
||||
Wir arbeiteten sowohl mit PantUML und Mermaid, aber ich habe jetzt draw.io entdeckt und bin davon begeistert.
|
||||
Könntest du mir im Zuge dessen mir diese Diagramme usw. auf draw.io umschreiben?
|
||||
|
||||
---
|
||||
Gemini
|
||||
---
|
||||
|
||||
🏗️ **[Lead Architect] & 🎨 [Frontend Expert]**
|
||||
|
||||
Das ist eine absolut sinnvolle Priorisierung! Bevor wir uns in die komplexe Welt der Nennungen stürzen, muss das Fundament (die "Schubladen" in der Desktop-App) stehen. Wenn der Prozess der Turnieranlage unübersichtlich ist, scheitert das System an der Benutzerakzeptanz.
|
||||
|
||||
### 1. Architektur-Diagramme & Draw.io Migration
|
||||
|
||||
Ich habe mir die alten `.puml` (PlantUML) und `.mermaid` Diagramme angesehen. Da diese teilweise veraltet waren und Sie draw.io bevorzugen, habe ich die Architektur-Diagramme komplett auf `.drawio` migriert und modernisiert:
|
||||
|
||||
* **`container_diagram.drawio` (Neu):** Ersetzt die alten Container-Diagramme. Es zeigt klar den Offline-First-Ansatz (Desktop App mit lokaler SQLite) und die Synchronisation mit dem Cloud-Backend.
|
||||
* **`workflow_turnieranlage.drawio` (Neu):** Ein komplett neues Flussdiagramm, das exakt den unten beschriebenen 3-stufigen Wizard-Prozess für die Desktop-App visualisiert.
|
||||
|
||||
*(Hinweis: Sie können die alten `.puml` und `.mermaid` Dateien im Ordner `docs/01_Architecture/c4/` nun gefahrlos löschen, um das Repository sauber zu halten).*
|
||||
|
||||
---
|
||||
|
||||
### 2. Der Desktop-App Workflow: "Kleine, händelbare Einheiten"
|
||||
|
||||
Um die UI/UX in der Desktop-App (Compose Multiplatform) wartbar und spartenspezifisch zu entwickeln, brechen wir den "Turnier anlegen"-Prozess in einen sauberen **3-stufigen Wizard** herunter. Dies entspricht exakt unserer Domain-Hierarchie:
|
||||
|
||||
#### 🟢 Schritt 1: Die Veranstaltung (Das Event-Wochenende)
|
||||
*Das ist die organisatorische "Klammer" für alles Weitere.*
|
||||
* **Basisdaten:** Name (z.B. "Pferdesporttage Neumarkt"), Zeitraum, Ort.
|
||||
* **Stammdaten-Import:** Upload der `ZNS.zip`. Das befüllt unseren lokalen Offline-Pool mit Reitern, Pferden und Funktionären für dieses Wochenende.
|
||||
* **Infrastruktur:** Anlegen der Austragungsplätze (z.B. "Waldarena", "Vorbereitungsplatz").
|
||||
* **Preisliste:** Definieren der Zusatzartikel (z.B. "Heu", "Ansage", "Tagesbox"), die der Veranstalter verkauft.
|
||||
|
||||
#### 🟡 Schritt 2: Das Turnier (Der offizielle Rahmen)
|
||||
*Hier konfigurieren wir den eigentlichen sportlichen Wettbewerb.*
|
||||
* **Identifikation:** Eingabe der 5-stelligen OEPS-Nummer (z.B. `26128`), Auswahl von Reglement (ÖTO), Sparte (Springen) und Kategorie (CSN-C).
|
||||
* **Regelwerk:** Festlegen von Nennschluss, Nachnenngebühren und Nenntauschbörse.
|
||||
* **Teilnehmerkreis:** Eventuelle Einschränkungen (Haflinger, Noriker, etc.) nach ÖTO § 3.
|
||||
* **Der "Chef":** Zuweisung des Turnierbeauftragten (TB) aus dem zuvor geladenen Funktionärs-Pool.
|
||||
* **Nenndaten-Import:** Upload der `n2-26128.dat` (falls Nennungen vom ZNS kommen).
|
||||
|
||||
#### 🟠 Schritt 3: Die Bewerbe (Das sportliche Programm)
|
||||
*Dies ist die feinste Granularität – hier entsteht der Zeitplan.*
|
||||
* **Identifikation:** Bewerbsnummer, Bezeichnung, Klasse/Höhe und die genaue Aufgabe (z.B. "R1").
|
||||
* **Ort & Zeit:** Zuweisung zu einem Austragungsplatz, Beginnzeit (Fix/Anschließend), Reitdauer und Pausen (Umbau/Besichtigung).
|
||||
* **Funktionäre:** Zuweisung der Richter auf spezifische Positionen (z.B. "C", "M") mit unserer "Warn-Logik" für Qualifikationen.
|
||||
* **Finanzen:** Festlegen von Startgeld und ob Preisgeld ausbezahlt wird.
|
||||
* **Die Teilungsregel:** Das Wichtigste! Wie wird geteilt? (z.B. `NACH_LIZENZ`, `MANUELL`).
|
||||
|
||||
---
|
||||
|
||||
**Nächster Schritt für uns:**
|
||||
Sollen wir als 🎨 **[Frontend Expert]** genau diesen Wizard (Schritt 1 bis 3) jetzt in Compose Multiplatform als UI-Komponenten (Screens/ViewModels) konzipieren und implementieren, damit Sie die Turnieranlage in der Desktop-App testen können?
|
||||
|
||||
|
||||
|
||||
|
||||
Reference in New Issue
Block a user