mocode-software/meldestelle
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
7ff48ed3d7
meldestelle/docs/04_Agents/Roadmaps/Backend_Roadmap.md
Stefan Mogeritsch f4844eb428 fix(tests): resolve EntriesIsolationIntegrationTest failures with test-specific DB config 
- Added `TestExposedConfiguration` to connect Exposed with Spring `DataSource` in the `test` profile.
- Downgraded `springdoc` version from `3.0.0` to `2.8.9` for Spring Boot 3.x compatibility.
- Applied `@ActiveProfiles("test")` to `EntriesIsolationIntegrationTest`.
- Updated roadmap documentation to reflect bugfix and test success.

Signed-off-by: Stefan Mogeritsch <stefan.mo.co@gmail.com>
2026-04-03 10:24:08 +02:00

5.2 KiB
Raw Blame History

👷 [Backend Developer] — Zwischenstand & Roadmap

Stand: 3. April 2026 Rolle: Spring Boot / Ktor, Kotlin, SQL, API-Design, Datenbankschema, Services

✅ Erledigte Sprints

Sprint A (Teilweise) — Abgeschlossene Punkte

  • A-2 | Datenbankschema: Domänen-Hierarchie umgesetzt
    • Tabellen veranstaltungen, turniere, bewerbe, abteilungen mit FK-Ketten
    • teilnehmer_konten (Veranstaltungsebene), turnier_kassa (Turnierebene)
    • Flyway-Migrationen V1–V3 (inkl. Turnier-Status DRAFT/PUBLISHED)
    • DomainHierarchyMigrationTest grün

🔴 Sprint A — Offen (höchste Priorität)

  • A-1 | Tenant-Isolation vollständig ausrollen ⚠️ BLOCKER

    • ADR-0021 übernommen; TenantWebFilter, TenantRegistry (JDBC) implementiert
    • Entries Service: JdbcTenantRegistry, TenantMigrationsRunner, MDC-Logging
    • Flyway pro Tenant-Schema; Unit-Tests (JdbcTenantRegistryTest) grün
    • Rollout auf weitere Services — masterdata/events/zns-import nutzen kein eigenes Tenant-Schema ( Single-Tenant-Architektur per ADR-0021 korrekt; nur Entries-Service ist Multi-Tenant)
    • E2E-Isolationstest re-enabled (@Disabled entfernt; EntriesIsolationIntegrationTest aktiv)
    • E2E-Test-Bugfix: springdoc von 3.0.0 → 2.8.9 (ClassNotFoundException behoben); @ActiveProfiles("test") + TestExposedConfiguration ergänzt (Exposed DB-Connect im Test-Profil); alle Tests grün ✅

  • A-3 | Validierungs-Grundlage: Turnierkategorie-Limits

    • Entkoppelte Policy-Schnittstelle + Bewerb-Descriptor implementiert
    • Konkrete ÖTO-Regeln/Limits umgesetzt (eigene Policy-Implementierung)
    • Sonderregeln aus 📜 Rulebook B-2 Spezifikation einarbeiten (wartet auf Übergabe)

🟠 Sprint B — Priorität 2 (diese Woche)

  • B-1 | CRUD-Endpunkte vervollständigen

    • Veranstaltung: GET, PUT
    • Turniere: POST, GET, GET{id}, PUT, DELETE, PATCH /status
    • Bewerbe: POST, GET, GET{id}, PUT, DELETE
    • Abteilungen: POST, GET, GET{id}, PUT, DELETE
    • Konsistentes Error-Format (problem+json); Service-Guardrails für PUBLISHED-Lock
    • Reiter: GET (Liste/Suche/Einzeln/Satznummer), POST, PUT, DELETE — Filter: lizenzKlasse, vereinId
    • Pferde: GET (Liste/Suche/Einzeln/Lebensnummer), POST, PUT, DELETE — Filter: jahrgang, besitzerId
    • Vereine: GET (Liste/Suche/Einzeln/Nummer), POST, PUT, DELETE — Filter: verband (Bundesland)
    • Funktionäre: GET (Liste/Suche/Einzeln/Richternummer), POST, PUT, DELETE — Filter: rolle
    • OpenAPI-Dokumentation (Springdoc) veröffentlichen
    • E2E-Tests: CRUD-Flows Turnier → Bewerb → Abteilung inkl. FK-Constraints

  • B-2 | Kassa-Service implementieren

    • TeilnehmerKonto-Service: Saldo aus mehreren Turnieren aggregieren
    • Zahlvorgang-Service: Zahlung auf Veranstaltungs-Ebene buchen
    • Rechnungs-Generierung: Separate Rechnung je Turnier aus einem Zahlvorgang
    • Endpunkte: GET /veranstaltungen/{id}/kassa/saldo, POST /veranstaltungen/{id}/zahlvorgaenge

  • B-3 | ÖTO-Validierung serverseitig absichern

    • Spezifikation von 📜 Rulebook B-2 umsetzen (wartet auf Übergabe)
    • OEPS-Nummern-Format, FEI-ID-Format validieren
    • Lizenzklassen-Validierung (R1–R4, LZF)
    • Altersklassen-Kompatibilität Pferd × Bewerb
    • Abteilungs-Zwangsteilung CSN-C-NEU (≤95cm: ohne/mit Lizenz; ≥100cm: R1/R2+)

🟡 Sprint C — Priorität 3 (nächste Woche)

  • C-1 | Nennungs-Service (Grundstruktur)

    • Tabelle nennungen anlegen (FK → abteilung_id, Status-Automat)
    • NennungsService: Erstellen, Prüfen, Bestätigen, Ablehnen
    • Nennungs-Workflow-Endpunkte

  • C-2 | Stammdaten-Seeder

    • Initiale Testdaten (Reiter, Pferde, Vereine) für Entwicklungsumgebung
    • Seed-Skript in config/scripts/ ablegen

  • C-3 | LAN-Sync-Endpunkte (ADR-0022 ✅ freigegeben)

    • SyncEvent-Datenmodell in core-Modul definieren (KMP-shared, Phase 1)
    • SQLDelight-Tabellen sync_events, sync_snapshots anlegen
    • LamportClock-Implementierung (thread-safe, persistent)
    • WebSocket-Server auf Meldestelle-Desk (Ktor): HELLO/HELLO_ACK/SYNC_DELTA/SYNC_PUSH
    • mDNS-Discovery-Service integrieren (gemäß ADR-0020)
    • Domänen-Mastership-Validierung im Event-Handler
    • Reconnect-Logik mit Delta-Sync (lastKnownSeq)

📌 Abhängigkeiten

Warte auf Von wem Betrifft
Rulebook B-2 Spezifikation 📜 Rulebook A-3, B-3
ADR-0022 (LAN-Sync) ✅ Erledigt C-3 freigegeben

💡 Empfehlungen (nach Priorität)

  1. A-3 / B-3 Sonderregeln & ÖTO-Validierung — Warten auf Rulebook B-2 Übergabe; Validator-Interface-Grundstruktur kann schon vorbereitet werden.
  2. B-1 OpenAPI — Springdoc-Dokumentation für alle neuen Endpunkte (Reiter/Pferde/Vereine/Funktionäre) veröffentlichen.
  3. B-2 Kassa-Service — Nächster großer Block nach Abschluss der CRUD-Endpunkte.