This commit is contained in:
Hymmel 2026-02-10 08:22:29 +01:00
parent 94170330c7
commit 0b5ecf12d5
2 changed files with 176 additions and 0 deletions

124
DATENMODELL.md Normal file
View file

@ -0,0 +1,124 @@
# Datenmodell & Struktur
## Entity-Relationship-Modell (ERM)
Das Datenmodell basiert auf vier Hauptentitäten: `User`, `Ticket`, `Room` und `Comment`.
```mermaid
erDiagram
USER ||--o{ TICKET : "erstellt / own"
USER ||--o{ COMMENT : "verfasst"
USER }|--|{ ROOM : "betreut (supervises)"
ROOM ||--o{ TICKET : "beinhaltet"
TICKET ||--o{ COMMENT : "hat"
USER {
Long id PK
String email
String password
String role
String firstname
String lastname
String theme
}
ROOM {
Long id PK
String name
}
TICKET {
Long id PK
String title_de
String title_en
String description_de
String description_en
String status
LocalDateTime createdAt
Long user_id FK
Long room_id FK
}
COMMENT {
Long id PK
String text
LocalDateTime createdAt
Long user_id FK
Long ticket_id FK
}
```
### Beziehungen Erklärung
1. **User - Ticket (1:N)**: Ein Benutzer kann viele Tickets erstellen. Ein Ticket gehört immer genau einem Benutzer (Ersteller).
2. **User - Comment (1:N)**: Ein Benutzer kann viele Kommentare verfassen.
3. **User - Room (N:M)**: Ein Benutzer (z.B. Raumbetreuer) kann für mehrere Räume zuständig sein. Ein Raum kann von mehreren Benutzern betreut werden. Diese Beziehung wird über eine Join-Tabelle `user_rooms` abgebildet.
4. **Room - Ticket (1:N)**: Ein Ticket bezieht sich immer auf einen spezifischen Raum. In einem Raum können viele Tickets gemeldet werden.
5. **Ticket - Comment (1:N)**: Ein Ticket kann mehrere Kommentare enthalten (Diskussionsverlauf).
---
## Klassendiagramm (Backend Entitäten)
Die Implementierung im Spring Boot Backend (`de.itsolutions.ticketsystem.entity`) spiegelt das ERM wider.
```mermaid
classDiagram
class User {
-Long id
-String name_firstname
-String name_lastname
-String email
-String password
-String role
-String theme
-List~Room~ supervisedRooms
+getId()
+getName()
+getEmail()
+getRole()
}
class Ticket {
-Long id
-String title_de
-String title_en
-String description_de
-String description_en
-String status
-LocalDateTime createdAt
-User owner
-Room room
+getTitle()
+getDescription()
+getStatus()
+getOwner()
}
class Room {
-Long id
-String name
+getId()
+getName()
}
class Comment {
-Long id
-String text
-LocalDateTime createdAt
-User author
-Ticket ticket
+getText()
+getAuthor()
}
User "1" --> "*" Ticket : owner
User "1" --> "*" Comment : author
User "*" --> "*" Room : supervisedRooms
Room "1" --> "*" Ticket : room
Ticket "1" --> "*" Comment : comments
```
### Anmerkungen zur Implementierung
* **Mehrsprachigkeit**: Die Entität `Ticket` speichert Titel und Beschreibung sowohl in Deutsch (`_de`) als auch in Englisch (`_en`), um Mehrsprachigkeit direkt auf Datenbankebene zu unterstützen.
* **Sicherheit**: Das Passwort im `User` Objekt wird gehasht gespeichert (BCrypt).
* **Zeitstempel**: `createdAt` Felder werden automatisch bei der Instanziierung (`LocalDateTime.now()`) gesetzt.

52
SYSTEM_UEBERSICHT.md Normal file
View file

@ -0,0 +1,52 @@
# Systemübersicht & Verwendete Technologien
## Frontend
Das Frontend wurde als moderne Single-Page-Application (SPA) entwickelt und setzt auf folgende Technologien:
* **Framework**: Next.js 16 (React 19)
* Sprache: TypeScript
* Routing: App Router
* **Styling**: Tailwind CSS
* Komponentenbibliothek: Shadcn UI (basiert auf Radix UI)
* Icons: Lucide React
* **State & Form Management**:
* React Hook Form (Formularvalidierung)
* Zod (Schema-Validierung)
* **Authentifizierung**: NextAuth.js
* **Visualisierung**: Recharts (Diagramme)
* **Datum/Zeit**: Date-fns
## Backend
Das Backend ist als RESTful API konzipiert und basiert auf dem Spring Boot Framework:
* **Framework**: Spring Boot 3.2.2
* Sprache: Java 21
* **Sicherheit**: Spring Security (JWT / Session Handling, CORS Konfiguration)
* **Datenbankzugriff**: Spring Data JPA (Hibernate)
* **Tools**: Lombok (zur Reduzierung von Boilerplate-Code)
* **Build Tool**: Maven
## Datenbank
Als Datenbank kommt ein relationales Datenbankmanagementsystem zum Einsatz:
* **System**: PostgreSQL 16 (Betrieb via Docker)
* **Name**: `ticketsystem`
* **Verbindung**: JDBC
## Probleme & Lösungen
### CORS (Cross-Origin Resource Sharing)
Ein wesentliches Problem während der Entwicklung war die CORS-Konfiguration (`Cross-Origin Resource Sharing`).
* **Problem**: Da Frontend (z.B. `localhost:3000`) und Backend (z.B. `localhost:8080` oder Docker-Netzwerk) auf unterschiedlichen Origins laufen, blockierten Browser standardmäßig die API-Anfragen des Frontends aus Sicherheitsgründen.
* **Lösung**: Implementierung einer globalen CORS-Konfiguration im Backend (`SecurityConfig.java`).
* Es wurde eine `CorsConfigurationSource` definiert.
* Explizite Freigabe der erlaubten Origins:
* `http://localhost:3000` (Lokale Entwicklung)
* `https://projekt.lona-development.org` (Produktion Frontend)
* `https://projektbackend.lona-development.org` (Produktion Backend)
* Erlaubte HTTP-Methoden: `GET`, `POST`, `PUT`, `PATCH`, `DELETE`, `OPTIONS`.
* Credentials (`setAllowCredentials(true)`) wurden aktiviert, um Authentifizierungs-Cookies/Header zuzulassen.
### Weitere Herausforderungen
* **Docker Networking**: Konfiguration der Kommunikation zwischen Frontend- und Backend-Containern über das interne Docker-Netzwerk (`ticketsystem-network`), während das Frontend teilweise auch clientseitig (im Browser des Users) auf die API zugreifen muss. Die Lösung bestand darin, Umgebungsvariablen für API-URLs flexibel zu gestalten (`NEXT_PUBLIC_API_URL`).