chore: Remove old Anhang and add some code to the docs
All checks were successful
Build docs / build-docs (pull_request) Successful in 29s
Label PRs based on size / Check PR size (pull_request) Successful in 27s
CI / Get Changed Files (pull_request) Successful in 34s
CI / Backend Tests (pull_request) Has been skipped
CI / eslint (pull_request) Has been skipped
Pull Request Labeler / labeler (pull_request_target) Successful in 4s
CI / Checkstyle Main (pull_request) Has been skipped
CI / oxlint (pull_request) Has been skipped
CI / Docker frontend validation (pull_request) Has been skipped
CI / prettier (pull_request) Has been skipped
CI / Docker backend validation (pull_request) Has been skipped
CI / test-build (pull_request) Has been skipped
CI / Playwright (pull_request) Has been skipped
Claude PR Review / claude-code (pull_request) Successful in 1m41s

This commit is contained in:
Jan K9f 2025-06-12 15:28:31 +02:00
commit 0e9e729fdf
10 changed files with 489 additions and 53 deletions

View file

@ -27,7 +27,7 @@ Services übernehmen die Kommunikation mit dem Backend und kapseln die Geschäft
\subsubsection{Backend-Architektur}
Das Backend implementiert eine klassische mehrschichtige Architektur, die eine klare Trennung der Verantwortlichkeiten gewährleistet. Die Controller-Schicht stellt die REST-\acs{API}-Endpunkte bereit und behandelt \acs{HTTP}-Anfragen. Die Service-Schicht enthält die Geschäftslogik und orchestriert verschiedene Use Cases.
Die Repository-Schicht abstrahiert den Datenzugriff und verwendet Spring Data JPA für die Kommunikation mit der Datenbank. Entity-Klassen repräsentieren die Domain-Modelle und bilden die Datenbankstrukturen ab.
Die Repository-Schicht abstrahiert den Datenzugriff und verwendet Spring Data JPA für die Kommunikation mit der Datenbank. Entity-Klassen repräsentieren die Domain-Modelle und bilden die Datenbankstrukturen ab. Eine detaillierte Darstellung der verschiedenen Architekturschichten mit konkreten Code-Beispielen findet sich im Anhang (siehe \ref{app:CodeSchichten}).
\subsection{Datenarchitektur}
Die Datenbank folgt einem relationalen Design mit klar definierten Entitätsbeziehungen. Das Schema gliedert sich in mehrere Hauptbereiche: Der User Management Bereich verwaltet Benutzerkonten und Benutzerprofile. Spielbezogene Daten wie Spielstände, Wetten und Ergebnisse werden in separaten Tabellen gespeichert, um die Integrität der Spiellogik zu gewährleisten.