refactoring Dokumentation
This commit is contained in:
@@ -1,130 +0,0 @@
|
||||
# Bilingual Documentation Index / Zweisprachiger Dokumentations-Index
|
||||
|
||||
## Overview / Übersicht
|
||||
|
||||
This document provides a comprehensive index of all bilingual documentation available in the Meldestelle project. All technical documentation is provided in both English and German versions to ensure accessibility for all team members and stakeholders.
|
||||
|
||||
Dieses Dokument bietet einen umfassenden Index aller zweisprachigen Dokumentation im Meldestelle-Projekt. Alle technische Dokumentation wird sowohl in englischer als auch in deutscher Version bereitgestellt, um die Zugänglichkeit für alle Teammitglieder und Stakeholder zu gewährleisten.
|
||||
|
||||
## Summary Documents / Zusammenfassungs-Dokumente
|
||||
|
||||
### Database Implementation / Datenbank-Implementierung
|
||||
|
||||
| English | German | Description |
|
||||
|---------|--------|-------------|
|
||||
| [DATABASE_FIXES_SUMMARY.md](./database/DATABASE_FIXES_SUMMARY.md) | [DATABASE_FIXES_SUMMARY-de.md](./database/DATABASE_FIXES_SUMMARY-de.md) | Database initialization fixes implementation summary |
|
||||
| [DATABASE_DIAGNOSTIC_REPORT-en.md](./database/DATABASE_DIAGNOSTIC_REPORT-en.md) | [DATABASE_DIAGNOSTIC_REPORT.md](./database/DATABASE_DIAGNOSTIC_REPORT.md) | Comprehensive database diagnostic analysis |
|
||||
| [STARTUP_ORDER_ANALYSIS.md](./database/STARTUP_ORDER_ANALYSIS.md) | [STARTUP_ORDER_ANALYSIS-de.md](./database/STARTUP_ORDER_ANALYSIS-de.md) | Startup order coordination analysis |
|
||||
|
||||
### Service Implementation / Service-Implementierung
|
||||
|
||||
| English | German | Description |
|
||||
|---------|--------|-------------|
|
||||
| [IMPLEMENTATION_SUMMARY.md](./implementation/IMPLEMENTATION_SUMMARY.md) | [IMPLEMENTATION_SUMMARY-de.md](./implementation/IMPLEMENTATION_SUMMARY-de.md) | Overall service implementation summary |
|
||||
| [HORSES_MODULE_OPTIMIZATION_SUMMARY.md](./modules/HORSES_MODULE_OPTIMIZATION_SUMMARY.md) | [HORSES_MODULE_OPTIMIZATION_SUMMARY-de.md](./modules/HORSES_MODULE_OPTIMIZATION_SUMMARY-de.md) | Horses module analysis and optimization |
|
||||
| [MEMBERS_MODULE_OPTIMIZATION_SUMMARY.md](./modules/MEMBERS_MODULE_OPTIMIZATION_SUMMARY.md) | [MEMBERS_MODULE_OPTIMIZATION_SUMMARY-de.md](./modules/MEMBERS_MODULE_OPTIMIZATION_SUMMARY-de.md) | Members module analysis and optimization |
|
||||
|
||||
### Client Implementation / Client-Implementierung
|
||||
|
||||
| English | German | Description |
|
||||
|---------|--------|-------------|
|
||||
| [CLIENT_OPTIMIZATION_SUMMARY-en.md](./client/CLIENT_OPTIMIZATION_SUMMARY-en.md) | [CLIENT_OPTIMIZATION_SUMMARY.md](./client/CLIENT_OPTIMIZATION_SUMMARY.md) | Client implementation optimization summary |
|
||||
|
||||
## Architecture Documentation / Architektur-Dokumentation
|
||||
|
||||
### Architecture Decision Records (ADRs)
|
||||
|
||||
| English | German | Description |
|
||||
|---------|--------|-------------|
|
||||
| [docs/architecture/adr/0004-event-driven-communication.md](./docs/architecture/adr/0004-event-driven-communication.md) | [docs/architecture/adr/0004-event-driven-communication-de.md](./docs/architecture/adr/0004-event-driven-communication-de.md) | Event-driven communication pattern |
|
||||
| [docs/architecture/adr/0005-polyglot-persistence.md](./docs/architecture/adr/0005-polyglot-persistence.md) | [docs/architecture/adr/0005-polyglot-persistence-de.md](./docs/architecture/adr/0005-polyglot-persistence-de.md) | Polyglot persistence strategy |
|
||||
| [docs/architecture/adr/0006-authentication-authorization-keycloak.md](./docs/architecture/adr/0006-authentication-authorization-keycloak.md) | [docs/architecture/adr/0006-authentication-authorization-keycloak-de.md](./docs/architecture/adr/0006-authentication-authorization-keycloak-de.md) | Authentication and authorization with Keycloak |
|
||||
| [docs/architecture/adr/0007-api-gateway-pattern.md](./docs/architecture/adr/0007-api-gateway-pattern.md) | [docs/architecture/adr/0007-api-gateway-pattern-de.md](./docs/architecture/adr/0007-api-gateway-pattern-de.md) | API Gateway pattern implementation |
|
||||
| [docs/architecture/adr/0008-multiplatform-client-applications.md](./docs/architecture/adr/0008-multiplatform-client-applications.md) | [docs/architecture/adr/0008-multiplatform-client-applications-de.md](./docs/architecture/adr/0008-multiplatform-client-applications-de.md) | Multiplatform client applications |
|
||||
|
||||
### C4 Architecture Diagrams
|
||||
|
||||
| English | German | Description |
|
||||
|---------|--------|-------------|
|
||||
| [docs/architecture/c4/03-component-events-service.puml](./docs/architecture/c4/03-component-events-service.puml) | [docs/architecture/c4/03-component-events-service-de.puml](./docs/architecture/c4/03-component-events-service-de.puml) | Events service component diagram |
|
||||
|
||||
## Development Documentation / Entwicklungs-Dokumentation
|
||||
|
||||
| English | German | Description |
|
||||
|---------|--------|-------------|
|
||||
| [docs/development/getting-started.md](./docs/development/getting-started.md) | [docs/development/getting-started-de.md](./docs/development/getting-started-de.md) | Getting started guide for developers |
|
||||
| [docs/development/environment-variables.md](./docs/development/environment-variables.md) | [docs/development/environment-variables-de.md](./docs/development/environment-variables-de.md) | Environment variables documentation |
|
||||
|
||||
## Migration Documentation / Migrations-Dokumentation
|
||||
|
||||
| English | German | Description |
|
||||
|---------|--------|-------------|
|
||||
| [docs/migration-summary.md](./docs/migration-summary.md) | [docs/migration-summary-de.md](./docs/migration-summary-de.md) | Migration summary and recommendations |
|
||||
| [docs/migration-status.md](./docs/migration-status.md) | [docs/migration-status-de.md](./docs/migration-status-de.md) | Current migration status |
|
||||
| [docs/migration-plan.md](./docs/migration-plan.md) | [docs/migration-plan-de.md](./docs/migration-plan-de.md) | Detailed migration plan |
|
||||
|
||||
## Implementation Reports / Implementierungs-Berichte
|
||||
|
||||
| English | German | Description |
|
||||
|---------|--------|-------------|
|
||||
| [docs/final-report.md](./docs/final-report.md) | [docs/final-report-de.md](./docs/final-report-de.md) | Final implementation report |
|
||||
| [docs/client-data-fetching-implementation-summary.md](./docs/client-data-fetching-implementation-summary.md) | [docs/client-data-fetching-implementation-summary-de.md](./docs/client-data-fetching-implementation-summary-de.md) | Client data fetching implementation |
|
||||
|
||||
## Configuration Documentation / Konfigurations-Dokumentation
|
||||
|
||||
| English | German | Description |
|
||||
|---------|--------|-------------|
|
||||
| [config/ssl/README.md](./config/ssl/README.md) | [config/ssl/README-de.md](./config/ssl/README-de.md) | SSL configuration guide |
|
||||
|
||||
## Documentation Standards / Dokumentations-Standards
|
||||
|
||||
### Naming Convention / Namenskonvention
|
||||
|
||||
- **English documents**: Use standard filename (e.g., `document-name.md`)
|
||||
- **German documents**: Add `-de` suffix (e.g., `document-name-de.md`)
|
||||
- **Englische Dokumente**: Verwenden Sie den Standard-Dateinamen (z.B. `document-name.md`)
|
||||
- **Deutsche Dokumente**: Fügen Sie das Suffix `-de` hinzu (z.B. `document-name-de.md`)
|
||||
|
||||
### Content Standards / Inhalts-Standards
|
||||
|
||||
- All technical documentation must be available in both languages
|
||||
- Translations should maintain technical accuracy and consistency
|
||||
- Code examples and technical terms should remain consistent across languages
|
||||
- Update dates should be synchronized between language versions
|
||||
|
||||
- Alle technische Dokumentation muss in beiden Sprachen verfügbar sein
|
||||
- Übersetzungen sollten technische Genauigkeit und Konsistenz beibehalten
|
||||
- Code-Beispiele und technische Begriffe sollten sprachübergreifend konsistent bleiben
|
||||
- Aktualisierungsdaten sollten zwischen den Sprachversionen synchronisiert werden
|
||||
|
||||
## Validation / Validierung
|
||||
|
||||
The project includes automated validation scripts to ensure documentation completeness:
|
||||
|
||||
Das Projekt enthält automatisierte Validierungsskripte zur Sicherstellung der Dokumentationsvollständigkeit:
|
||||
|
||||
- `scripts/validation/validate-docs.sh` - Validates bilingual documentation coverage
|
||||
- `scripts/validation/validate-docs.sh` - Validiert die zweisprachige Dokumentationsabdeckung
|
||||
|
||||
## Contributing / Mitwirken
|
||||
|
||||
When creating or updating documentation:
|
||||
|
||||
Beim Erstellen oder Aktualisieren von Dokumentation:
|
||||
|
||||
1. **Always provide both language versions** / **Stellen Sie immer beide Sprachversionen bereit**
|
||||
2. **Maintain consistent formatting** / **Behalten Sie konsistente Formatierung bei**
|
||||
3. **Update this index when adding new documents** / **Aktualisieren Sie diesen Index beim Hinzufügen neuer Dokumente**
|
||||
4. **Run validation scripts before committing** / **Führen Sie Validierungsskripte vor dem Commit aus**
|
||||
|
||||
## Last Updated / Letzte Aktualisierung
|
||||
|
||||
- **Date / Datum**: July 25, 2025 / 25. Juli 2025
|
||||
- **Version / Version**: 1.0.0
|
||||
- **Total Documents / Gesamtdokumente**: 14 bilingual pairs / 14 zweisprachige Paare
|
||||
|
||||
---
|
||||
|
||||
*This index is automatically maintained and should be updated whenever new bilingual documentation is added to the project.*
|
||||
|
||||
*Dieser Index wird automatisch gepflegt und sollte aktualisiert werden, wenn neue zweisprachige Dokumentation zum Projekt hinzugefügt wird.*
|
||||
-229
@@ -1,229 +0,0 @@
|
||||
# Meldestelle Documentation Index
|
||||
|
||||
## 📚 Vollständige Dokumentationsübersicht
|
||||
|
||||
Willkommen zur umfassenden Dokumentation des Meldestelle-Systems. Diese Übersicht bietet strukturierten Zugang zu allen verfügbaren Dokumenten und Ressourcen.
|
||||
|
||||
---
|
||||
|
||||
## 🏗️ Architektur und Design
|
||||
|
||||
### Hauptdokumentation
|
||||
- **[Projekt-Übersicht](../README.md)** - Systemüberblick und Schnellstart
|
||||
- **[Produktionsumgebung](../README-PRODUCTION.md)** - Produktions-Setup und Sicherheit
|
||||
- **[Umgebungsvariablen](../README-ENV.md)** - Konfiguration und Setup
|
||||
|
||||
### Architektur-Dokumentation
|
||||
- **[Architektur-Übersicht](architecture/)** - Systemarchitektur und Design-Entscheidungen
|
||||
- **[C4-Diagramme](architecture/c4/)** - Visuelle Architektur-Darstellung
|
||||
|
||||
---
|
||||
|
||||
## 🔧 Module-Dokumentation
|
||||
|
||||
### Core-Module
|
||||
- **[Core Module](../core/README.md)** - Shared Kernel und gemeinsame Komponenten
|
||||
- Domain-Modelle und Enumerationen
|
||||
- Utilities und Konfiguration
|
||||
- Fehlerbehandlung und Validierung
|
||||
- Service Discovery
|
||||
|
||||
### Geschäfts-Module
|
||||
|
||||
#### Members (Mitgliederverwaltung)
|
||||
- **[Members Module](../members/README.md)** - Umfassende Mitgliederverwaltung
|
||||
- 18+ Repository-Operationen
|
||||
- Mitgliedschafts-Tracking
|
||||
- Validierung und Geschäftsregeln
|
||||
|
||||
#### Horses (Pferderegistrierung)
|
||||
- **[Horses Module](../horses/README.md)** - Pferderegistrierung und -verwaltung
|
||||
- 25+ Repository-Operationen
|
||||
- OEPS/FEI-Integration
|
||||
- Identifikationsnummern-Verwaltung
|
||||
|
||||
#### Events (Veranstaltungsverwaltung)
|
||||
- **[Events Module](../events/README.md)** - Veranstaltungsplanung und -verwaltung
|
||||
- 10+ Repository-Operationen
|
||||
- Terminverwaltung
|
||||
- Sparten-Management
|
||||
|
||||
#### Masterdata (Stammdatenverwaltung)
|
||||
- **[Masterdata Module](../masterdata/README.md)** - Stammdaten für das gesamte System
|
||||
- 37+ REST-Endpunkte
|
||||
- Länder, Bundesländer, Altersklassen
|
||||
- Turnierplätze und Austragungsorte
|
||||
|
||||
### Infrastruktur-Module
|
||||
- **[Infrastructure Module](../infrastructure/README.md)** - Technische Infrastruktur
|
||||
- Authentication & Authorization
|
||||
- Caching und Event Store
|
||||
- API Gateway und Messaging
|
||||
- Monitoring und Observability
|
||||
|
||||
### Client-Module
|
||||
- **[Client Module](../client/README.md)** - Benutzeroberflächen
|
||||
- Web-Anwendung und Desktop-App
|
||||
- Repository-Pattern und API-Client
|
||||
- UI-Komponenten und Theme System
|
||||
|
||||
---
|
||||
|
||||
## 🔌 API-Dokumentation
|
||||
|
||||
### REST-API-Übersicht
|
||||
- **[API-Übersicht](api/README.md)** - Vollständige REST-API-Dokumentation
|
||||
- Technische Spezifikationen
|
||||
- Authentifizierung und Autorisierung
|
||||
- Rate Limiting und Fehlerbehandlung
|
||||
|
||||
### Modul-spezifische APIs
|
||||
- **[Members API](api/members-api.md)** - Mitgliederverwaltung API
|
||||
- 12 REST-Endpunkte
|
||||
- Datenmodelle und Validierung
|
||||
- Praktische Workflows
|
||||
|
||||
### Automatisch generierte API-Dokumentation
|
||||
- **[Generated OpenAPI Specs](api/generated/)** - Automatisch generierte OpenAPI-Spezifikationen
|
||||
- Members API OpenAPI
|
||||
- Horses API OpenAPI
|
||||
- Events API OpenAPI
|
||||
- Masterdata API OpenAPI
|
||||
|
||||
---
|
||||
|
||||
## 👨💻 Entwicklerdokumentation
|
||||
|
||||
### Erste Schritte
|
||||
- **[Entwicklungsanleitung](development/getting-started-de.md)** - Vollständige Einrichtungsanleitung
|
||||
- Systemanforderungen und Software-Installation
|
||||
- Projekt-Setup und IDE-Konfiguration
|
||||
- Entwicklungsworkflows und Debugging
|
||||
|
||||
### Umgebung und Konfiguration
|
||||
- **[Umgebungsvariablen](development/environment-variables-de.md)** - Detaillierte Konfigurationsdokumentation
|
||||
|
||||
### Implementierung
|
||||
- **[Redis-Integration](implementation/redis-integration-de.md)** - Redis-Implementierungsdetails
|
||||
|
||||
---
|
||||
|
||||
## 🔄 Migration und Deployment
|
||||
|
||||
### Migration
|
||||
- **[Migrations-Plan](migration-plan-de.md)** - Detaillierter Migrationsplan
|
||||
- **[Migrations-Zusammenfassung](migration-summary-de.md)** - Übersicht abgeschlossener Aufgaben
|
||||
- **[Migrations-Status](migration-status-de.md)** - Aktueller Migrationsstatus
|
||||
- **[Verbleibende Aufgaben](migration-remaining-tasks-de.md)** - Noch zu erledigende Arbeiten
|
||||
- **[Abschlussbericht](final-report-de.md)** - Projekt-Restrukturierung Abschlussbericht
|
||||
|
||||
### SSL und Sicherheit
|
||||
- **[SSL-Konfiguration](../config/ssl/README-de.md)** - Produktions-SSL-Setup
|
||||
|
||||
---
|
||||
|
||||
## 🎨 Client-Entwicklung
|
||||
|
||||
### Architektur und Patterns
|
||||
- **[Client-Implementierung](client-data-fetching-implementation-summary-de.md)** - Datenabruf und Zustandsverwaltung
|
||||
- **[Client-Verbesserungen](client-data-fetching-improvements-de.md)** - Zukünftige Erweiterungen
|
||||
|
||||
---
|
||||
|
||||
## 📊 Dokumentations-Management
|
||||
|
||||
### Qualitätssicherung
|
||||
- **[Dokumentations-Updates](documentation-updates-summary.md)** - Vollständige Übersicht aller Dokumentationsaktualisierungen
|
||||
- 18 neue Dokumentationsdateien
|
||||
- 6.012 Zeilen hochwertige Dokumentation
|
||||
- 100% Modulabdeckung
|
||||
|
||||
### Automatisierung
|
||||
- **Automatische Validierung**: CI/CD-Pipeline für Dokumentationsqualität
|
||||
- **OpenAPI-Generierung**: Automatische API-Dokumentationsgenerierung
|
||||
- **Link-Validierung**: Automatische Überprüfung aller Dokumentationslinks
|
||||
|
||||
---
|
||||
|
||||
## 🔍 Schnellzugriff
|
||||
|
||||
### Nach Zielgruppe
|
||||
|
||||
#### Neue Entwickler
|
||||
1. [Entwicklungsanleitung](development/getting-started-de.md)
|
||||
2. [Projekt-Übersicht](../README.md)
|
||||
3. [Core Module](../core/README.md)
|
||||
4. [API-Übersicht](api/README.md)
|
||||
|
||||
#### API-Entwickler
|
||||
1. [API-Übersicht](api/README.md)
|
||||
2. [Members API](api/members-api.md)
|
||||
3. [Generated OpenAPI Specs](api/generated/)
|
||||
4. [Authentifizierung](../README-PRODUCTION.md#sicherheit)
|
||||
|
||||
#### DevOps-Engineers
|
||||
1. [Produktionsumgebung](../README-PRODUCTION.md)
|
||||
2. [SSL-Konfiguration](../config/ssl/README-de.md)
|
||||
3. [Umgebungsvariablen](../README-ENV.md)
|
||||
4. [Infrastructure Module](../infrastructure/README.md)
|
||||
|
||||
#### Architekten
|
||||
1. [Architektur-Dokumentation](architecture/)
|
||||
2. [C4-Diagramme](architecture/c4/)
|
||||
3. [Migrations-Plan](migration-plan-de.md)
|
||||
4. [Abschlussbericht](final-report-de.md)
|
||||
|
||||
### Nach Technologie
|
||||
|
||||
#### Backend (Kotlin/Spring Boot)
|
||||
- [Core Module](../core/README.md)
|
||||
- [Members Module](../members/README.md)
|
||||
- [Infrastructure Module](../infrastructure/README.md)
|
||||
|
||||
#### Frontend (Compose)
|
||||
- [Client Module](../client/README.md)
|
||||
- [Client-Implementierung](client-data-fetching-implementation-summary-de.md)
|
||||
|
||||
#### Datenbank (PostgreSQL)
|
||||
- [Migrations-Plan](migration-plan-de.md)
|
||||
- [Entwicklungsanleitung](development/getting-started-de.md#datenbank-migrationen)
|
||||
|
||||
#### Infrastruktur (Docker/Kubernetes)
|
||||
- [Produktionsumgebung](../README-PRODUCTION.md)
|
||||
- [Infrastructure Module](../infrastructure/README.md)
|
||||
|
||||
---
|
||||
|
||||
## 📈 Dokumentationsstatistiken
|
||||
|
||||
- **📄 Dokumentationsdateien**: 18 neue Dateien erstellt
|
||||
- **📝 Gesamtzeilen**: 6.012 Zeilen hochwertiger Dokumentation
|
||||
- **🎯 Modulabdeckung**: 100% (6/6 Module vollständig dokumentiert)
|
||||
- **🔗 API-Abdeckung**: 100% (vollständige REST-API-Dokumentation)
|
||||
- **🇩🇪 Deutsche Inhalte**: 95% aller Dokumentation auf Deutsch verfügbar
|
||||
- **💡 Code-Beispiele**: 200+ praktische Code-Snippets
|
||||
|
||||
---
|
||||
|
||||
## 🔄 Letzte Aktualisierungen
|
||||
|
||||
**25. Juli 2025**: Umfassende Dokumentationsaktualisierung
|
||||
- Alle Module vollständig dokumentiert
|
||||
- Deutsche Übersetzungen erstellt
|
||||
- API-Dokumentation vervollständigt
|
||||
- Entwicklungsanleitungen hinzugefügt
|
||||
- Automatisierung implementiert
|
||||
|
||||
---
|
||||
|
||||
## 📞 Support und Beitrag
|
||||
|
||||
- **Issue Tracker**: GitHub Issues für Dokumentationsfehler
|
||||
- **Verbesserungsvorschläge**: Pull Requests willkommen
|
||||
- **Automatische Validierung**: CI/CD-Pipeline prüft alle Änderungen
|
||||
|
||||
---
|
||||
|
||||
**Letzte Aktualisierung**: 25. Juli 2025
|
||||
**Dokumentationsversion**: 1.0
|
||||
**Vollständigkeit**: 100%
|
||||
+2
-2
@@ -36,12 +36,12 @@ API Services
|
||||
|
||||
### Entwicklungsumgebung
|
||||
```
|
||||
Base URL: http://localhost:8080/api
|
||||
Base URL: http://localhost:8081/api
|
||||
```
|
||||
|
||||
### Produktionsumgebung
|
||||
```
|
||||
Base URL: https://api.meldestelle.at/api
|
||||
Base URL: https://api.meldestelle.yourdomain.com/api
|
||||
```
|
||||
|
||||
## API-Module Übersicht
|
||||
|
||||
@@ -0,0 +1,189 @@
|
||||
# Client Implementation Optimization Summary
|
||||
|
||||
## Übersicht
|
||||
|
||||
Dieses Dokument fasst die durchgeführten Optimierungen der Client-Implementierungen im Meldestelle-System zusammen. Die Optimierungen zielen darauf ab, Code-Duplikation zu reduzieren, die Architektur zu verbessern und die Build-Konfigurationen zu optimieren.
|
||||
|
||||
## Durchgeführte Optimierungen
|
||||
|
||||
### 1. Konfigurierbare API-Client-Einstellungen ✅
|
||||
|
||||
**Datei:** `client/common-ui/src/main/kotlin/at/mocode/client/common/config/ApiConfig.kt`
|
||||
|
||||
**Verbesserungen:**
|
||||
- Umgebungsvariablen-basierte Konfiguration für API-Einstellungen
|
||||
- Konfigurierbare Base-URL, Timeouts, Cache-Einstellungen
|
||||
- Unterstützung für System Properties und Umgebungsvariablen
|
||||
- Logging-Konfiguration
|
||||
|
||||
**Vorteile:**
|
||||
- Flexibilität für verschiedene Umgebungen (Dev, Test, Prod)
|
||||
- Keine hardcodierten Werte mehr
|
||||
- Einfache Konfiguration ohne Code-Änderungen
|
||||
|
||||
### 2. Verbesserte Cache-Implementierung ✅
|
||||
|
||||
**Datei:** `client/common-ui/src/main/kotlin/at/mocode/client/common/cache/ApiCache.kt`
|
||||
|
||||
**Verbesserungen:**
|
||||
- LRU (Least Recently Used) Eviction-Strategie
|
||||
- Thread-sichere Implementierung mit ReentrantReadWriteLock
|
||||
- Konfigurierbare Cache-Größe und TTL
|
||||
- Pattern-basierte Cache-Invalidierung
|
||||
- Cache-Statistiken und Cleanup-Funktionen
|
||||
|
||||
**Vorteile:**
|
||||
- Bessere Speicherverwaltung durch Größenbegrenzung
|
||||
- Verbesserte Performance durch intelligente Eviction
|
||||
- Konsistente Daten durch automatische Invalidierung
|
||||
- Monitoring-Möglichkeiten durch Statistiken
|
||||
|
||||
### 3. Base Repository Klasse ✅
|
||||
|
||||
**Datei:** `client/common-ui/src/main/kotlin/at/mocode/client/common/repository/BaseClientRepository.kt`
|
||||
|
||||
**Verbesserungen:**
|
||||
- Gemeinsame CRUD-Operationen für alle Repositories
|
||||
- Einheitliche Fehlerbehandlung
|
||||
- Konsistente Logging-Mechanismen
|
||||
- Cache-Invalidierung nach Änderungsoperationen
|
||||
- Wiederverwendbare Suchmethoden
|
||||
|
||||
**Vorteile:**
|
||||
- Eliminierung von Code-Duplikation zwischen Repositories
|
||||
- Konsistente Fehlerbehandlung über alle Repositories
|
||||
- Einfachere Wartung und Erweiterung
|
||||
- Reduzierte Entwicklungszeit für neue Repositories
|
||||
|
||||
### 4. Optimierte Repository-Implementierung ✅
|
||||
|
||||
**Datei:** `client/common-ui/src/main/kotlin/at/mocode/client/common/repository/OptimizedClientPersonRepository.kt`
|
||||
|
||||
**Verbesserungen:**
|
||||
- Nutzung der BaseClientRepository-Klasse
|
||||
- Automatische Cache-Invalidierung nach Änderungen
|
||||
- Verbesserte Fehlerbehandlung
|
||||
- Konsistente Logging-Mechanismen
|
||||
|
||||
**Vorteile:**
|
||||
- Weniger Code-Duplikation
|
||||
- Bessere Wartbarkeit
|
||||
- Konsistente Funktionalität
|
||||
|
||||
### 5. Optimierte Build-Konfigurationen ✅
|
||||
|
||||
#### Desktop App (`client/desktop-app/build.gradle.kts.optimized`)
|
||||
|
||||
**Entfernte unnötige Dependencies:**
|
||||
- Spring Boot (nicht für Desktop-Client benötigt)
|
||||
- Redis-Dependencies (Redisson, Lettuce)
|
||||
- Direkte Domain-Modul-Dependencies
|
||||
- Unnötige Infrastructure-Dependencies
|
||||
|
||||
**Hinzugefügte Verbesserungen:**
|
||||
- Desktop-spezifische Coroutines (swing statt javafx)
|
||||
- Native Distribution-Konfiguration
|
||||
- Plattform-spezifische Icons und Packaging
|
||||
|
||||
#### Web App (`client/web-app/build.gradle.kts.optimized`)
|
||||
|
||||
**Entfernte unnötige Dependencies:**
|
||||
- Direkte Domain-Modul-Dependencies
|
||||
- Members-Application-Layer-Dependencies
|
||||
- Unnötige Infrastructure-Dependencies
|
||||
|
||||
**Hinzugefügte Verbesserungen:**
|
||||
- Web-spezifische Compose-Dependencies
|
||||
- Bessere Test-Dependencies (MockK, JUnit 5)
|
||||
- Web-spezifische Coroutines
|
||||
|
||||
## Architektur-Verbesserungen
|
||||
|
||||
### Vor der Optimierung:
|
||||
```
|
||||
Desktop App
|
||||
├── Spring Boot ❌
|
||||
├── Redis Dependencies ❌
|
||||
├── Direct Domain Access ❌
|
||||
├── Heavy Infrastructure ❌
|
||||
└── Code Duplication ❌
|
||||
|
||||
Web App
|
||||
├── Direct Domain Access ❌
|
||||
├── Application Layer Dependencies ❌
|
||||
├── Inconsistent Error Handling ❌
|
||||
└── Code Duplication ❌
|
||||
```
|
||||
|
||||
### Nach der Optimierung:
|
||||
```
|
||||
Desktop App
|
||||
├── Minimal Dependencies ✅
|
||||
├── API-Only Access ✅
|
||||
├── Shared Components ✅
|
||||
└── Clean Architecture ✅
|
||||
|
||||
Web App
|
||||
├── API-Only Access ✅
|
||||
├── Shared Base Classes ✅
|
||||
├── Consistent Error Handling ✅
|
||||
└── Optimized Dependencies ✅
|
||||
```
|
||||
|
||||
## Quantifizierte Verbesserungen
|
||||
|
||||
### Code-Reduktion:
|
||||
- **Repository Code:** ~60% Reduktion durch BaseClientRepository
|
||||
- **Build Dependencies:** ~40% Reduktion in Desktop App
|
||||
- **Build Dependencies:** ~30% Reduktion in Web App
|
||||
|
||||
### Performance-Verbesserungen:
|
||||
- **Cache Efficiency:** LRU-Eviction statt einfacher TTL
|
||||
- **Memory Usage:** Begrenzte Cache-Größe verhindert Memory Leaks
|
||||
- **Build Time:** Weniger Dependencies = schnellere Builds
|
||||
|
||||
### Wartbarkeit:
|
||||
- **Einheitliche Fehlerbehandlung** über alle Repositories
|
||||
- **Konfigurierbare Einstellungen** ohne Code-Änderungen
|
||||
- **Konsistente Logging-Mechanismen**
|
||||
- **Wiederverwendbare Komponenten**
|
||||
|
||||
## Identifizierte weitere Optimierungsmöglichkeiten
|
||||
|
||||
### Kurzfristig:
|
||||
1. **Logging Framework:** Ersetzen von `println` durch SLF4J
|
||||
2. **Retry Logic:** Implementierung von Retry-Mechanismen für API-Calls
|
||||
3. **Connection Pooling:** Optimierung der HTTP-Client-Konfiguration
|
||||
4. **Request/Response Interceptors:** Für Monitoring und Debugging
|
||||
|
||||
### Mittelfristig:
|
||||
1. **Reactive Streams:** Migration zu reaktiven Datenströmen
|
||||
2. **Offline Support:** Implementierung von Offline-Funktionalität
|
||||
3. **Progressive Web App:** Erweiterung der Web-App zu PWA
|
||||
4. **State Management:** Implementierung von zentralem State Management
|
||||
|
||||
### Langfristig:
|
||||
1. **Microservices Gateway:** Implementierung eines API-Gateways
|
||||
2. **GraphQL Integration:** Migration von REST zu GraphQL
|
||||
3. **Real-time Updates:** WebSocket-Integration für Live-Updates
|
||||
4. **Mobile Apps:** Erweiterung um native Mobile Apps
|
||||
|
||||
## Empfohlene nächste Schritte
|
||||
|
||||
1. **Tests aktualisieren:** Die bestehenden Tests sind zu stark an Domain-Layer gekoppelt und sollten refactored werden
|
||||
2. **Logging Framework einführen:** SLF4J statt println verwenden
|
||||
3. **Optimierte Build-Konfigurationen aktivieren:** Die `.optimized` Dateien als Standard übernehmen
|
||||
4. **Monitoring implementieren:** Cache-Statistiken und API-Performance überwachen
|
||||
5. **Dokumentation erweitern:** API-Dokumentation und Entwickler-Guidelines erstellen
|
||||
|
||||
## Fazit
|
||||
|
||||
Die durchgeführten Optimierungen verbessern die Client-Implementierungen erheblich:
|
||||
|
||||
- **Reduzierte Komplexität** durch weniger Dependencies
|
||||
- **Bessere Wartbarkeit** durch gemeinsame Base-Klassen
|
||||
- **Verbesserte Performance** durch optimierte Caching-Strategien
|
||||
- **Flexiblere Konfiguration** durch umgebungsbasierte Einstellungen
|
||||
- **Sauberere Architektur** durch API-only Zugriff auf Backend-Services
|
||||
|
||||
Diese Optimierungen legen eine solide Grundlage für die weitere Entwicklung und Skalierung des Meldestelle-Systems.
|
||||
@@ -1,193 +0,0 @@
|
||||
# Client Implementation Optimization Summary
|
||||
|
||||
## Overview
|
||||
|
||||
This document summarizes the optimizations performed on the client implementations in the Meldestelle system. The optimizations aim to reduce code duplication, improve architecture, and optimize build configurations.
|
||||
|
||||
## Performed Optimizations
|
||||
|
||||
### 1. Configurable API Client Settings ✅
|
||||
|
||||
**File:** `client/common-ui/src/main/kotlin/at/mocode/client/common/config/ApiConfig.kt`
|
||||
|
||||
**Improvements:**
|
||||
- Environment variable-based configuration for API settings
|
||||
- Configurable base URL, timeouts, cache settings
|
||||
- Support for system properties and environment variables
|
||||
- Logging configuration
|
||||
|
||||
**Benefits:**
|
||||
- Flexibility for different environments (Dev, Test, Prod)
|
||||
- No more hardcoded values
|
||||
- Easy configuration without code changes
|
||||
|
||||
### 2. Improved Cache Implementation ✅
|
||||
|
||||
**File:** `client/common-ui/src/main/kotlin/at/mocode/client/common/cache/ApiCache.kt`
|
||||
|
||||
**Improvements:**
|
||||
- LRU (Least Recently Used) eviction strategy
|
||||
- Thread-safe implementation with ReentrantReadWriteLock
|
||||
- Configurable cache size and TTL
|
||||
- Pattern-based cache invalidation
|
||||
- Cache statistics and cleanup functions
|
||||
|
||||
**Benefits:**
|
||||
- Better memory management through size limitation
|
||||
- Improved performance through intelligent eviction
|
||||
- Consistent data through automatic invalidation
|
||||
- Monitoring capabilities through statistics
|
||||
|
||||
### 3. Base Repository Class ✅
|
||||
|
||||
**File:** `client/common-ui/src/main/kotlin/at/mocode/client/common/repository/BaseClientRepository.kt`
|
||||
|
||||
**Improvements:**
|
||||
- Common CRUD operations for all repositories
|
||||
- Unified error handling
|
||||
- Consistent logging mechanisms
|
||||
- Cache invalidation after modification operations
|
||||
- Reusable search methods
|
||||
|
||||
**Benefits:**
|
||||
- Elimination of code duplication between repositories
|
||||
- Consistent error handling across all repositories
|
||||
- Easier maintenance and extension
|
||||
- Reduced development time for new repositories
|
||||
|
||||
### 4. Optimized Repository Implementation ✅
|
||||
|
||||
**File:** `client/common-ui/src/main/kotlin/at/mocode/client/common/repository/OptimizedClientPersonRepository.kt`
|
||||
|
||||
**Improvements:**
|
||||
- Usage of BaseClientRepository class
|
||||
- Automatic cache invalidation after changes
|
||||
- Improved error handling
|
||||
- Consistent logging mechanisms
|
||||
|
||||
**Benefits:**
|
||||
- Less code duplication
|
||||
- Better maintainability
|
||||
- Consistent functionality
|
||||
|
||||
### 5. Optimized Build Configurations ✅
|
||||
|
||||
#### Desktop App (`client/desktop-app/build.gradle.kts.optimized`)
|
||||
|
||||
**Removed unnecessary dependencies:**
|
||||
- Spring Boot (not needed for desktop client)
|
||||
- Redis dependencies (Redisson, Lettuce)
|
||||
- Direct domain module dependencies
|
||||
- Unnecessary infrastructure dependencies
|
||||
|
||||
**Added improvements:**
|
||||
- Desktop-specific coroutines (swing instead of javafx)
|
||||
- Native distribution configuration
|
||||
- Platform-specific icons and packaging
|
||||
|
||||
#### Web App (`client/web-app/build.gradle.kts.optimized`)
|
||||
|
||||
**Removed unnecessary dependencies:**
|
||||
- Direct domain module dependencies
|
||||
- Members application layer dependencies
|
||||
- Unnecessary infrastructure dependencies
|
||||
|
||||
**Added improvements:**
|
||||
- Web-specific Compose dependencies
|
||||
- Better test dependencies (MockK, JUnit 5)
|
||||
- Web-specific coroutines
|
||||
|
||||
## Architecture Improvements
|
||||
|
||||
### Before Optimization:
|
||||
```
|
||||
Desktop App
|
||||
├── Spring Boot ❌
|
||||
├── Redis Dependencies ❌
|
||||
├── Direct Domain Access ❌
|
||||
├── Heavy Infrastructure ❌
|
||||
└── Code Duplication ❌
|
||||
|
||||
Web App
|
||||
├── Direct Domain Access ❌
|
||||
├── Application Layer Dependencies ❌
|
||||
├── Inconsistent Error Handling ❌
|
||||
└── Code Duplication ❌
|
||||
```
|
||||
|
||||
### After Optimization:
|
||||
```
|
||||
Desktop App
|
||||
├── Minimal Dependencies ✅
|
||||
├── API-Only Access ✅
|
||||
├── Shared Components ✅
|
||||
└── Clean Architecture ✅
|
||||
|
||||
Web App
|
||||
├── API-Only Access ✅
|
||||
├── Shared Base Classes ✅
|
||||
├── Consistent Error Handling ✅
|
||||
└── Optimized Dependencies ✅
|
||||
```
|
||||
|
||||
## Quantified Improvements
|
||||
|
||||
### Code Reduction:
|
||||
- **Repository Code:** ~60% reduction through BaseClientRepository
|
||||
- **Build Dependencies:** ~40% reduction in Desktop App
|
||||
- **Build Dependencies:** ~30% reduction in Web App
|
||||
|
||||
### Performance Improvements:
|
||||
- **Cache Efficiency:** LRU eviction instead of simple TTL
|
||||
- **Memory Usage:** Limited cache size prevents memory leaks
|
||||
- **Build Time:** Fewer dependencies = faster builds
|
||||
|
||||
### Maintainability:
|
||||
- **Unified error handling** across all repositories
|
||||
- **Configurable settings** without code changes
|
||||
- **Consistent logging mechanisms**
|
||||
- **Reusable components**
|
||||
|
||||
## Identified Further Optimization Opportunities
|
||||
|
||||
### Short-term:
|
||||
1. **Logging Framework:** Replace `println` with SLF4J
|
||||
2. **Retry Logic:** Implement retry mechanisms for API calls
|
||||
3. **Connection Pooling:** Optimize HTTP client configuration
|
||||
4. **Request/Response Interceptors:** For monitoring and debugging
|
||||
|
||||
### Medium-term:
|
||||
1. **Reactive Streams:** Migration to reactive data streams
|
||||
2. **Offline Support:** Implementation of offline functionality
|
||||
3. **Progressive Web App:** Extension of web app to PWA
|
||||
4. **State Management:** Implementation of central state management
|
||||
|
||||
### Long-term:
|
||||
1. **Microservices Gateway:** Implementation of an API gateway
|
||||
2. **GraphQL Integration:** Migration from REST to GraphQL
|
||||
3. **Real-time Updates:** WebSocket integration for live updates
|
||||
4. **Mobile Apps:** Extension with native mobile apps
|
||||
|
||||
## Recommended Next Steps
|
||||
|
||||
1. **Update tests:** Existing tests are too tightly coupled to domain layer and should be refactored
|
||||
2. **Introduce logging framework:** Use SLF4J instead of println
|
||||
3. **Activate optimized build configurations:** Adopt the `.optimized` files as standard
|
||||
4. **Implement monitoring:** Monitor cache statistics and API performance
|
||||
5. **Expand documentation:** Create API documentation and developer guidelines
|
||||
|
||||
## Conclusion
|
||||
|
||||
The performed optimizations significantly improve the client implementations:
|
||||
|
||||
- **Reduced complexity** through fewer dependencies
|
||||
- **Better maintainability** through shared base classes
|
||||
- **Improved performance** through optimized caching strategies
|
||||
- **More flexible configuration** through environment-based settings
|
||||
- **Cleaner architecture** through API-only access to backend services
|
||||
|
||||
These optimizations lay a solid foundation for further development and scaling of the Meldestelle system.
|
||||
|
||||
---
|
||||
|
||||
*Last updated: July 25, 2025*
|
||||
@@ -1,105 +1,105 @@
|
||||
# Client Implementation Optimization Summary
|
||||
|
||||
## Übersicht
|
||||
## Overview
|
||||
|
||||
Dieses Dokument fasst die durchgeführten Optimierungen der Client-Implementierungen im Meldestelle-System zusammen. Die Optimierungen zielen darauf ab, Code-Duplikation zu reduzieren, die Architektur zu verbessern und die Build-Konfigurationen zu optimieren.
|
||||
This document summarizes the optimizations performed on the client implementations in the Meldestelle system. The optimizations aim to reduce code duplication, improve architecture, and optimize build configurations.
|
||||
|
||||
## Durchgeführte Optimierungen
|
||||
## Performed Optimizations
|
||||
|
||||
### 1. Konfigurierbare API-Client-Einstellungen ✅
|
||||
### 1. Configurable API Client Settings ✅
|
||||
|
||||
**Datei:** `client/common-ui/src/main/kotlin/at/mocode/client/common/config/ApiConfig.kt`
|
||||
**File:** `client/common-ui/src/main/kotlin/at/mocode/client/common/config/ApiConfig.kt`
|
||||
|
||||
**Verbesserungen:**
|
||||
- Umgebungsvariablen-basierte Konfiguration für API-Einstellungen
|
||||
- Konfigurierbare Base-URL, Timeouts, Cache-Einstellungen
|
||||
- Unterstützung für System Properties und Umgebungsvariablen
|
||||
- Logging-Konfiguration
|
||||
**Improvements:**
|
||||
- Environment variable-based configuration for API settings
|
||||
- Configurable base URL, timeouts, cache settings
|
||||
- Support for system properties and environment variables
|
||||
- Logging configuration
|
||||
|
||||
**Vorteile:**
|
||||
- Flexibilität für verschiedene Umgebungen (Dev, Test, Prod)
|
||||
- Keine hardcodierten Werte mehr
|
||||
- Einfache Konfiguration ohne Code-Änderungen
|
||||
**Benefits:**
|
||||
- Flexibility for different environments (Dev, Test, Prod)
|
||||
- No more hardcoded values
|
||||
- Easy configuration without code changes
|
||||
|
||||
### 2. Verbesserte Cache-Implementierung ✅
|
||||
### 2. Improved Cache Implementation ✅
|
||||
|
||||
**Datei:** `client/common-ui/src/main/kotlin/at/mocode/client/common/cache/ApiCache.kt`
|
||||
**File:** `client/common-ui/src/main/kotlin/at/mocode/client/common/cache/ApiCache.kt`
|
||||
|
||||
**Verbesserungen:**
|
||||
- LRU (Least Recently Used) Eviction-Strategie
|
||||
- Thread-sichere Implementierung mit ReentrantReadWriteLock
|
||||
- Konfigurierbare Cache-Größe und TTL
|
||||
- Pattern-basierte Cache-Invalidierung
|
||||
- Cache-Statistiken und Cleanup-Funktionen
|
||||
**Improvements:**
|
||||
- LRU (Least Recently Used) eviction strategy
|
||||
- Thread-safe implementation with ReentrantReadWriteLock
|
||||
- Configurable cache size and TTL
|
||||
- Pattern-based cache invalidation
|
||||
- Cache statistics and cleanup functions
|
||||
|
||||
**Vorteile:**
|
||||
- Bessere Speicherverwaltung durch Größenbegrenzung
|
||||
- Verbesserte Performance durch intelligente Eviction
|
||||
- Konsistente Daten durch automatische Invalidierung
|
||||
- Monitoring-Möglichkeiten durch Statistiken
|
||||
**Benefits:**
|
||||
- Better memory management through size limitation
|
||||
- Improved performance through intelligent eviction
|
||||
- Consistent data through automatic invalidation
|
||||
- Monitoring capabilities through statistics
|
||||
|
||||
### 3. Base Repository Klasse ✅
|
||||
### 3. Base Repository Class ✅
|
||||
|
||||
**Datei:** `client/common-ui/src/main/kotlin/at/mocode/client/common/repository/BaseClientRepository.kt`
|
||||
**File:** `client/common-ui/src/main/kotlin/at/mocode/client/common/repository/BaseClientRepository.kt`
|
||||
|
||||
**Verbesserungen:**
|
||||
- Gemeinsame CRUD-Operationen für alle Repositories
|
||||
- Einheitliche Fehlerbehandlung
|
||||
- Konsistente Logging-Mechanismen
|
||||
- Cache-Invalidierung nach Änderungsoperationen
|
||||
- Wiederverwendbare Suchmethoden
|
||||
**Improvements:**
|
||||
- Common CRUD operations for all repositories
|
||||
- Unified error handling
|
||||
- Consistent logging mechanisms
|
||||
- Cache invalidation after modification operations
|
||||
- Reusable search methods
|
||||
|
||||
**Vorteile:**
|
||||
- Eliminierung von Code-Duplikation zwischen Repositories
|
||||
- Konsistente Fehlerbehandlung über alle Repositories
|
||||
- Einfachere Wartung und Erweiterung
|
||||
- Reduzierte Entwicklungszeit für neue Repositories
|
||||
**Benefits:**
|
||||
- Elimination of code duplication between repositories
|
||||
- Consistent error handling across all repositories
|
||||
- Easier maintenance and extension
|
||||
- Reduced development time for new repositories
|
||||
|
||||
### 4. Optimierte Repository-Implementierung ✅
|
||||
### 4. Optimized Repository Implementation ✅
|
||||
|
||||
**Datei:** `client/common-ui/src/main/kotlin/at/mocode/client/common/repository/OptimizedClientPersonRepository.kt`
|
||||
**File:** `client/common-ui/src/main/kotlin/at/mocode/client/common/repository/OptimizedClientPersonRepository.kt`
|
||||
|
||||
**Verbesserungen:**
|
||||
- Nutzung der BaseClientRepository-Klasse
|
||||
- Automatische Cache-Invalidierung nach Änderungen
|
||||
- Verbesserte Fehlerbehandlung
|
||||
- Konsistente Logging-Mechanismen
|
||||
**Improvements:**
|
||||
- Usage of BaseClientRepository class
|
||||
- Automatic cache invalidation after changes
|
||||
- Improved error handling
|
||||
- Consistent logging mechanisms
|
||||
|
||||
**Vorteile:**
|
||||
- Weniger Code-Duplikation
|
||||
- Bessere Wartbarkeit
|
||||
- Konsistente Funktionalität
|
||||
**Benefits:**
|
||||
- Less code duplication
|
||||
- Better maintainability
|
||||
- Consistent functionality
|
||||
|
||||
### 5. Optimierte Build-Konfigurationen ✅
|
||||
### 5. Optimized Build Configurations ✅
|
||||
|
||||
#### Desktop App (`client/desktop-app/build.gradle.kts.optimized`)
|
||||
|
||||
**Entfernte unnötige Dependencies:**
|
||||
- Spring Boot (nicht für Desktop-Client benötigt)
|
||||
- Redis-Dependencies (Redisson, Lettuce)
|
||||
- Direkte Domain-Modul-Dependencies
|
||||
- Unnötige Infrastructure-Dependencies
|
||||
**Removed unnecessary dependencies:**
|
||||
- Spring Boot (not needed for desktop client)
|
||||
- Redis dependencies (Redisson, Lettuce)
|
||||
- Direct domain module dependencies
|
||||
- Unnecessary infrastructure dependencies
|
||||
|
||||
**Hinzugefügte Verbesserungen:**
|
||||
- Desktop-spezifische Coroutines (swing statt javafx)
|
||||
- Native Distribution-Konfiguration
|
||||
- Plattform-spezifische Icons und Packaging
|
||||
**Added improvements:**
|
||||
- Desktop-specific coroutines (swing instead of javafx)
|
||||
- Native distribution configuration
|
||||
- Platform-specific icons and packaging
|
||||
|
||||
#### Web App (`client/web-app/build.gradle.kts.optimized`)
|
||||
|
||||
**Entfernte unnötige Dependencies:**
|
||||
- Direkte Domain-Modul-Dependencies
|
||||
- Members-Application-Layer-Dependencies
|
||||
- Unnötige Infrastructure-Dependencies
|
||||
**Removed unnecessary dependencies:**
|
||||
- Direct domain module dependencies
|
||||
- Members application layer dependencies
|
||||
- Unnecessary infrastructure dependencies
|
||||
|
||||
**Hinzugefügte Verbesserungen:**
|
||||
- Web-spezifische Compose-Dependencies
|
||||
- Bessere Test-Dependencies (MockK, JUnit 5)
|
||||
- Web-spezifische Coroutines
|
||||
**Added improvements:**
|
||||
- Web-specific Compose dependencies
|
||||
- Better test dependencies (MockK, JUnit 5)
|
||||
- Web-specific coroutines
|
||||
|
||||
## Architektur-Verbesserungen
|
||||
## Architecture Improvements
|
||||
|
||||
### Vor der Optimierung:
|
||||
### Before Optimization:
|
||||
```
|
||||
Desktop App
|
||||
├── Spring Boot ❌
|
||||
@@ -115,7 +115,7 @@ Web App
|
||||
└── Code Duplication ❌
|
||||
```
|
||||
|
||||
### Nach der Optimierung:
|
||||
### After Optimization:
|
||||
```
|
||||
Desktop App
|
||||
├── Minimal Dependencies ✅
|
||||
@@ -130,60 +130,64 @@ Web App
|
||||
└── Optimized Dependencies ✅
|
||||
```
|
||||
|
||||
## Quantifizierte Verbesserungen
|
||||
## Quantified Improvements
|
||||
|
||||
### Code-Reduktion:
|
||||
- **Repository Code:** ~60% Reduktion durch BaseClientRepository
|
||||
- **Build Dependencies:** ~40% Reduktion in Desktop App
|
||||
- **Build Dependencies:** ~30% Reduktion in Web App
|
||||
### Code Reduction:
|
||||
- **Repository Code:** ~60% reduction through BaseClientRepository
|
||||
- **Build Dependencies:** ~40% reduction in Desktop App
|
||||
- **Build Dependencies:** ~30% reduction in Web App
|
||||
|
||||
### Performance-Verbesserungen:
|
||||
- **Cache Efficiency:** LRU-Eviction statt einfacher TTL
|
||||
- **Memory Usage:** Begrenzte Cache-Größe verhindert Memory Leaks
|
||||
- **Build Time:** Weniger Dependencies = schnellere Builds
|
||||
### Performance Improvements:
|
||||
- **Cache Efficiency:** LRU eviction instead of simple TTL
|
||||
- **Memory Usage:** Limited cache size prevents memory leaks
|
||||
- **Build Time:** Fewer dependencies = faster builds
|
||||
|
||||
### Wartbarkeit:
|
||||
- **Einheitliche Fehlerbehandlung** über alle Repositories
|
||||
- **Konfigurierbare Einstellungen** ohne Code-Änderungen
|
||||
- **Konsistente Logging-Mechanismen**
|
||||
- **Wiederverwendbare Komponenten**
|
||||
### Maintainability:
|
||||
- **Unified error handling** across all repositories
|
||||
- **Configurable settings** without code changes
|
||||
- **Consistent logging mechanisms**
|
||||
- **Reusable components**
|
||||
|
||||
## Identifizierte weitere Optimierungsmöglichkeiten
|
||||
## Identified Further Optimization Opportunities
|
||||
|
||||
### Kurzfristig:
|
||||
1. **Logging Framework:** Ersetzen von `println` durch SLF4J
|
||||
2. **Retry Logic:** Implementierung von Retry-Mechanismen für API-Calls
|
||||
3. **Connection Pooling:** Optimierung der HTTP-Client-Konfiguration
|
||||
4. **Request/Response Interceptors:** Für Monitoring und Debugging
|
||||
### Short-term:
|
||||
1. **Logging Framework:** Replace `println` with SLF4J
|
||||
2. **Retry Logic:** Implement retry mechanisms for API calls
|
||||
3. **Connection Pooling:** Optimize HTTP client configuration
|
||||
4. **Request/Response Interceptors:** For monitoring and debugging
|
||||
|
||||
### Mittelfristig:
|
||||
1. **Reactive Streams:** Migration zu reaktiven Datenströmen
|
||||
2. **Offline Support:** Implementierung von Offline-Funktionalität
|
||||
3. **Progressive Web App:** Erweiterung der Web-App zu PWA
|
||||
4. **State Management:** Implementierung von zentralem State Management
|
||||
### Medium-term:
|
||||
1. **Reactive Streams:** Migration to reactive data streams
|
||||
2. **Offline Support:** Implementation of offline functionality
|
||||
3. **Progressive Web App:** Extension of web app to PWA
|
||||
4. **State Management:** Implementation of central state management
|
||||
|
||||
### Langfristig:
|
||||
1. **Microservices Gateway:** Implementierung eines API-Gateways
|
||||
2. **GraphQL Integration:** Migration von REST zu GraphQL
|
||||
3. **Real-time Updates:** WebSocket-Integration für Live-Updates
|
||||
4. **Mobile Apps:** Erweiterung um native Mobile Apps
|
||||
### Long-term:
|
||||
1. **Microservices Gateway:** Implementation of an API gateway
|
||||
2. **GraphQL Integration:** Migration from REST to GraphQL
|
||||
3. **Real-time Updates:** WebSocket integration for live updates
|
||||
4. **Mobile Apps:** Extension with native mobile apps
|
||||
|
||||
## Empfohlene nächste Schritte
|
||||
## Recommended Next Steps
|
||||
|
||||
1. **Tests aktualisieren:** Die bestehenden Tests sind zu stark an Domain-Layer gekoppelt und sollten refactored werden
|
||||
2. **Logging Framework einführen:** SLF4J statt println verwenden
|
||||
3. **Optimierte Build-Konfigurationen aktivieren:** Die `.optimized` Dateien als Standard übernehmen
|
||||
4. **Monitoring implementieren:** Cache-Statistiken und API-Performance überwachen
|
||||
5. **Dokumentation erweitern:** API-Dokumentation und Entwickler-Guidelines erstellen
|
||||
1. **Update tests:** Existing tests are too tightly coupled to domain layer and should be refactored
|
||||
2. **Introduce logging framework:** Use SLF4J instead of println
|
||||
3. **Activate optimized build configurations:** Adopt the `.optimized` files as standard
|
||||
4. **Implement monitoring:** Monitor cache statistics and API performance
|
||||
5. **Expand documentation:** Create API documentation and developer guidelines
|
||||
|
||||
## Fazit
|
||||
## Conclusion
|
||||
|
||||
Die durchgeführten Optimierungen verbessern die Client-Implementierungen erheblich:
|
||||
The performed optimizations significantly improve the client implementations:
|
||||
|
||||
- **Reduzierte Komplexität** durch weniger Dependencies
|
||||
- **Bessere Wartbarkeit** durch gemeinsame Base-Klassen
|
||||
- **Verbesserte Performance** durch optimierte Caching-Strategien
|
||||
- **Flexiblere Konfiguration** durch umgebungsbasierte Einstellungen
|
||||
- **Sauberere Architektur** durch API-only Zugriff auf Backend-Services
|
||||
- **Reduced complexity** through fewer dependencies
|
||||
- **Better maintainability** through shared base classes
|
||||
- **Improved performance** through optimized caching strategies
|
||||
- **More flexible configuration** through environment-based settings
|
||||
- **Cleaner architecture** through API-only access to backend services
|
||||
|
||||
Diese Optimierungen legen eine solide Grundlage für die weitere Entwicklung und Skalierung des Meldestelle-Systems.
|
||||
These optimizations lay a solid foundation for further development and scaling of the Meldestelle system.
|
||||
|
||||
---
|
||||
|
||||
*Last updated: July 25, 2025*
|
||||
|
||||
@@ -0,0 +1,148 @@
|
||||
# Database Diagnostic Report - Exposed Framework Initialization
|
||||
|
||||
## Diagnose Ergebnisse
|
||||
|
||||
### ✅ Database.connect() Aufrufe identifiziert
|
||||
|
||||
**Zentrale Implementierung:**
|
||||
- **DatabaseFactory.kt** (Zeile 66): `Database.connect(dataSource!!)`
|
||||
- Verwendet HikariCP Connection Pooling
|
||||
- Singleton-Pattern mit proper Konfiguration
|
||||
- Unterstützt Verbindungsvalidierung und Leak-Detection
|
||||
|
||||
**Service-spezifische Konfigurationen:**
|
||||
- **Events Service**: EventsDatabaseConfiguration.kt - verwendet DatabaseFactory.init()
|
||||
- **Horses Service**: DatabaseConfiguration.kt - verwendet DatabaseFactory.init()
|
||||
- **Members Service**: MembersDatabaseConfiguration.kt - verwendet DatabaseFactory.init()
|
||||
- **Masterdata Service**: MasterdataDatabaseConfiguration.kt - verwendet DatabaseFactory.init()
|
||||
|
||||
**⚠️ PROBLEM IDENTIFIZIERT - Gateway Konfiguration:**
|
||||
- **Gateway**: DatabaseConfig.kt (Zeile 25-30) - **direkter Database.connect() Aufruf**
|
||||
```kotlin
|
||||
Database.connect(
|
||||
url = databaseUrl,
|
||||
driver = "org.postgresql.Driver",
|
||||
user = databaseUser,
|
||||
password = databasePassword
|
||||
)
|
||||
```
|
||||
|
||||
### ✅ Exposed-Operationen (Transaktionen, Queries) lokalisiert
|
||||
|
||||
**Schema-Initialisierung (in @PostConstruct):**
|
||||
- Alle Services: `transaction { SchemaUtils.createMissingTablesAndColumns(...) }`
|
||||
- Gateway: `transaction { SchemaUtils.createMissingTablesAndColumns(...) }` für alle Kontexte
|
||||
|
||||
**Business Logic Transaktionen:**
|
||||
- **TransactionalCreateHorseUseCase**: Verwendet `DatabaseFactory.dbQuery { ... }`
|
||||
- **DatabaseMigrator**: Verwendet `transaction { ... }` für Migrationen
|
||||
|
||||
**Test-Transaktionen:**
|
||||
- SimpleDatabaseTest.kt: Direkte `transaction { ... }` Aufrufe in Tests
|
||||
|
||||
### ✅ Initialisierungsreihenfolge analysiert
|
||||
|
||||
**Korrekte Reihenfolge in Services:**
|
||||
1. `@PostConstruct` → `DatabaseFactory.init(config)` → `Database.connect()`
|
||||
2. Sofort danach: `transaction { SchemaUtils.createMissingTablesAndColumns(...) }`
|
||||
3. Business Logic: `DatabaseFactory.dbQuery { ... }` für Transaktionen
|
||||
|
||||
**⚠️ PROBLEM - Gateway Initialisierung:**
|
||||
1. Ktor Application.configureDatabase() → direkter `Database.connect()`
|
||||
2. Sofort danach: `transaction { ... }` für alle Service-Schemas
|
||||
|
||||
## 🚨 Identifizierte Probleme
|
||||
|
||||
### 1. **Inkonsistente Database.connect() Implementierung**
|
||||
- **Services**: Verwenden zentralen DatabaseFactory mit Connection Pooling
|
||||
- **Gateway**: Direkter Database.connect() ohne Connection Pooling
|
||||
- **Risiko**: Unterschiedliche Verbindungsqualität und -management
|
||||
|
||||
### 2. **Potentielle Race Conditions**
|
||||
- Gateway und Services initialisieren unabhängig voneinander
|
||||
- Beide versuchen, Schemas für dieselben Tabellen zu erstellen
|
||||
- **Risiko**: Konflikte bei paralleler Initialisierung
|
||||
|
||||
### 3. **Verletzung der Separation of Concerns**
|
||||
- Gateway verwaltet Schemas für alle Services
|
||||
- Services verwalten ihre eigenen Schemas
|
||||
- **Risiko**: Doppelte Schema-Initialisierung
|
||||
|
||||
### 4. **Fehlende Initialisierungsreihenfolge-Garantien**
|
||||
- Keine explizite Abhängigkeitsreihenfolge zwischen Gateway und Services
|
||||
- **Risiko**: Exposed-Operationen vor Database.connect()
|
||||
|
||||
## ✅ Empfehlungen
|
||||
|
||||
### 1. **Gateway auf DatabaseFactory umstellen**
|
||||
```kotlin
|
||||
// Statt direktem Database.connect():
|
||||
fun Application.configureDatabase() {
|
||||
val config = DatabaseConfig.fromEnv() // oder aus Ktor Config
|
||||
DatabaseFactory.init(config)
|
||||
// Schema-Initialisierung entfernen oder koordinieren
|
||||
}
|
||||
```
|
||||
|
||||
### 2. **Schema-Initialisierung koordinieren**
|
||||
**Option A**: Nur Services verwalten ihre Schemas (empfohlen)
|
||||
```kotlin
|
||||
// Gateway: Nur Verbindung, keine Schema-Initialisierung
|
||||
fun Application.configureDatabase() {
|
||||
DatabaseFactory.init(DatabaseConfig.fromEnv())
|
||||
}
|
||||
```
|
||||
|
||||
**Option B**: Zentralisierte Schema-Verwaltung
|
||||
```kotlin
|
||||
// Separater DatabaseSchemaInitializer mit @Order Annotation
|
||||
@Component
|
||||
@Order(Ordered.HIGHEST_PRECEDENCE)
|
||||
class DatabaseSchemaInitializer {
|
||||
@PostConstruct
|
||||
fun initializeAllSchemas() {
|
||||
// Schema initialization logic
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### 3. **Startup-Reihenfolge sicherstellen**
|
||||
```kotlin
|
||||
// Services mit @DependsOn
|
||||
@Configuration
|
||||
@DependsOn("databaseInitializer")
|
||||
class HorsesDatabaseConfiguration {
|
||||
// Configuration logic
|
||||
}
|
||||
```
|
||||
|
||||
### 4. **Einheitliche Konfiguration**
|
||||
```kotlin
|
||||
// Alle Komponenten verwenden DatabaseFactory
|
||||
class SomeService {
|
||||
suspend fun doSomething() {
|
||||
DatabaseFactory.dbQuery {
|
||||
// Exposed operations
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## 📋 Zusammenfassung
|
||||
|
||||
**✅ Korrekt implementiert:**
|
||||
- Alle Services verwenden proper @PostConstruct → Database.connect() → Exposed operations Reihenfolge
|
||||
- DatabaseFactory bietet robuste Connection Pool Konfiguration
|
||||
- Business Logic verwendet korrekte Transaktionsmuster
|
||||
|
||||
**⚠️ Zu beheben:**
|
||||
- Gateway Database.connect() Inkonsistenz
|
||||
- Potentielle Race Conditions bei Schema-Initialisierung
|
||||
- Fehlende Startup-Reihenfolge-Koordination
|
||||
|
||||
**🎯 Priorität:**
|
||||
1. **Hoch**: Gateway auf DatabaseFactory umstellen
|
||||
2. **Mittel**: Schema-Initialisierung koordinieren
|
||||
3. **Niedrig**: Startup-Reihenfolge explizit definieren
|
||||
|
||||
Die Reihenfolge der Initialisierung ist grundsätzlich korrekt, aber die Inkonsistenz zwischen Gateway und Services sollte behoben werden, um potentielle Probleme zu vermeiden.
|
||||
@@ -1,152 +0,0 @@
|
||||
# Database Diagnostic Report - Exposed Framework Initialization
|
||||
|
||||
## Diagnostic Results
|
||||
|
||||
### ✅ Database.connect() Calls Identified
|
||||
|
||||
**Central Implementation:**
|
||||
- **DatabaseFactory.kt** (Line 66): `Database.connect(dataSource!!)`
|
||||
- Uses HikariCP Connection Pooling
|
||||
- Singleton pattern with proper configuration
|
||||
- Supports connection validation and leak detection
|
||||
|
||||
**Service-specific Configurations:**
|
||||
- **Events Service**: EventsDatabaseConfiguration.kt - uses DatabaseFactory.init()
|
||||
- **Horses Service**: DatabaseConfiguration.kt - uses DatabaseFactory.init()
|
||||
- **Members Service**: MembersDatabaseConfiguration.kt - uses DatabaseFactory.init()
|
||||
- **Masterdata Service**: MasterdataDatabaseConfiguration.kt - uses DatabaseFactory.init()
|
||||
|
||||
**⚠️ PROBLEM IDENTIFIED - Gateway Configuration:**
|
||||
- **Gateway**: DatabaseConfig.kt (Lines 25-30) - **direct Database.connect() call**
|
||||
```kotlin
|
||||
Database.connect(
|
||||
url = databaseUrl,
|
||||
driver = "org.postgresql.Driver",
|
||||
user = databaseUser,
|
||||
password = databasePassword
|
||||
)
|
||||
```
|
||||
|
||||
### ✅ Exposed Operations (Transactions, Queries) Located
|
||||
|
||||
**Schema Initialization (in @PostConstruct):**
|
||||
- All Services: `transaction { SchemaUtils.createMissingTablesAndColumns(...) }`
|
||||
- Gateway: `transaction { SchemaUtils.createMissingTablesAndColumns(...) }` for all contexts
|
||||
|
||||
**Business Logic Transactions:**
|
||||
- **TransactionalCreateHorseUseCase**: Uses `DatabaseFactory.dbQuery { ... }`
|
||||
- **DatabaseMigrator**: Uses `transaction { ... }` for migrations
|
||||
|
||||
**Test Transactions:**
|
||||
- SimpleDatabaseTest.kt: Direct `transaction { ... }` calls in tests
|
||||
|
||||
### ✅ Initialization Order Analyzed
|
||||
|
||||
**Correct Order in Services:**
|
||||
1. `@PostConstruct` → `DatabaseFactory.init(config)` → `Database.connect()`
|
||||
2. Immediately after: `transaction { SchemaUtils.createMissingTablesAndColumns(...) }`
|
||||
3. Business Logic: `DatabaseFactory.dbQuery { ... }` for transactions
|
||||
|
||||
**⚠️ PROBLEM - Gateway Initialization:**
|
||||
1. Ktor Application.configureDatabase() → direct `Database.connect()`
|
||||
2. Immediately after: `transaction { ... }` for all service schemas
|
||||
|
||||
## 🚨 Identified Problems
|
||||
|
||||
### 1. **Inconsistent Database.connect() Implementation**
|
||||
- **Services**: Use central DatabaseFactory with Connection Pooling
|
||||
- **Gateway**: Direct Database.connect() without Connection Pooling
|
||||
- **Risk**: Different connection quality and management
|
||||
|
||||
### 2. **Potential Race Conditions**
|
||||
- Gateway and services initialize independently
|
||||
- Both attempt to create schemas for the same tables
|
||||
- **Risk**: Conflicts during parallel initialization
|
||||
|
||||
### 3. **Violation of Separation of Concerns**
|
||||
- Gateway manages schemas for all services
|
||||
- Services manage their own schemas
|
||||
- **Risk**: Duplicate schema initialization
|
||||
|
||||
### 4. **Missing Initialization Order Guarantees**
|
||||
- No explicit dependency order between Gateway and Services
|
||||
- **Risk**: Exposed operations before Database.connect()
|
||||
|
||||
## ✅ Recommendations
|
||||
|
||||
### 1. **Switch Gateway to DatabaseFactory**
|
||||
```kotlin
|
||||
// Instead of direct Database.connect():
|
||||
fun Application.configureDatabase() {
|
||||
val config = DatabaseConfig.fromEnv() // or from Ktor Config
|
||||
DatabaseFactory.init(config)
|
||||
// Remove or coordinate schema initialization
|
||||
}
|
||||
```
|
||||
|
||||
### 2. **Coordinate Schema Initialization**
|
||||
**Option A**: Only services manage their schemas (recommended)
|
||||
```kotlin
|
||||
// Gateway: Only connection, no schema initialization
|
||||
fun Application.configureDatabase() {
|
||||
DatabaseFactory.init(DatabaseConfig.fromEnv())
|
||||
}
|
||||
```
|
||||
|
||||
**Option B**: Centralized schema management
|
||||
```kotlin
|
||||
// Separate DatabaseSchemaInitializer with @Order annotation
|
||||
@Component
|
||||
@Order(Ordered.HIGHEST_PRECEDENCE)
|
||||
class DatabaseSchemaInitializer {
|
||||
@PostConstruct
|
||||
fun initializeAllSchemas() {
|
||||
// Schema initialization logic
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### 3. **Ensure Startup Order**
|
||||
```kotlin
|
||||
// Services with @DependsOn
|
||||
@Configuration
|
||||
@DependsOn("databaseInitializer")
|
||||
class HorsesDatabaseConfiguration {
|
||||
// Configuration logic
|
||||
}
|
||||
```
|
||||
|
||||
### 4. **Unified Configuration**
|
||||
```kotlin
|
||||
// All components use DatabaseFactory
|
||||
class SomeService {
|
||||
suspend fun doSomething() {
|
||||
DatabaseFactory.dbQuery {
|
||||
// Exposed operations
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## 📋 Summary
|
||||
|
||||
**✅ Correctly implemented:**
|
||||
- All services use proper @PostConstruct → Database.connect() → Exposed operations sequence
|
||||
- DatabaseFactory provides robust Connection Pool configuration
|
||||
- Business logic uses correct transaction patterns
|
||||
|
||||
**⚠️ To be fixed:**
|
||||
- Gateway Database.connect() inconsistency
|
||||
- Potential race conditions in schema initialization
|
||||
- Missing startup order coordination
|
||||
|
||||
**🎯 Priority:**
|
||||
1. **High**: Switch Gateway to DatabaseFactory
|
||||
2. **Medium**: Coordinate schema initialization
|
||||
3. **Low**: Explicitly define startup order
|
||||
|
||||
The initialization sequence is fundamentally correct, but the inconsistency between Gateway and Services should be resolved to avoid potential problems.
|
||||
|
||||
---
|
||||
|
||||
*Last updated: July 25, 2025*
|
||||
@@ -1,23 +1,23 @@
|
||||
# Database Diagnostic Report - Exposed Framework Initialization
|
||||
|
||||
## Diagnose Ergebnisse
|
||||
## Diagnostic Results
|
||||
|
||||
### ✅ Database.connect() Aufrufe identifiziert
|
||||
### ✅ Database.connect() Calls Identified
|
||||
|
||||
**Zentrale Implementierung:**
|
||||
- **DatabaseFactory.kt** (Zeile 66): `Database.connect(dataSource!!)`
|
||||
- Verwendet HikariCP Connection Pooling
|
||||
- Singleton-Pattern mit proper Konfiguration
|
||||
- Unterstützt Verbindungsvalidierung und Leak-Detection
|
||||
**Central Implementation:**
|
||||
- **DatabaseFactory.kt** (Line 66): `Database.connect(dataSource!!)`
|
||||
- Uses HikariCP Connection Pooling
|
||||
- Singleton pattern with proper configuration
|
||||
- Supports connection validation and leak detection
|
||||
|
||||
**Service-spezifische Konfigurationen:**
|
||||
- **Events Service**: EventsDatabaseConfiguration.kt - verwendet DatabaseFactory.init()
|
||||
- **Horses Service**: DatabaseConfiguration.kt - verwendet DatabaseFactory.init()
|
||||
- **Members Service**: MembersDatabaseConfiguration.kt - verwendet DatabaseFactory.init()
|
||||
- **Masterdata Service**: MasterdataDatabaseConfiguration.kt - verwendet DatabaseFactory.init()
|
||||
**Service-specific Configurations:**
|
||||
- **Events Service**: EventsDatabaseConfiguration.kt - uses DatabaseFactory.init()
|
||||
- **Horses Service**: DatabaseConfiguration.kt - uses DatabaseFactory.init()
|
||||
- **Members Service**: MembersDatabaseConfiguration.kt - uses DatabaseFactory.init()
|
||||
- **Masterdata Service**: MasterdataDatabaseConfiguration.kt - uses DatabaseFactory.init()
|
||||
|
||||
**⚠️ PROBLEM IDENTIFIZIERT - Gateway Konfiguration:**
|
||||
- **Gateway**: DatabaseConfig.kt (Zeile 25-30) - **direkter Database.connect() Aufruf**
|
||||
**⚠️ PROBLEM IDENTIFIED - Gateway Configuration:**
|
||||
- **Gateway**: DatabaseConfig.kt (Lines 25-30) - **direct Database.connect() call**
|
||||
```kotlin
|
||||
Database.connect(
|
||||
url = databaseUrl,
|
||||
@@ -27,75 +27,75 @@
|
||||
)
|
||||
```
|
||||
|
||||
### ✅ Exposed-Operationen (Transaktionen, Queries) lokalisiert
|
||||
### ✅ Exposed Operations (Transactions, Queries) Located
|
||||
|
||||
**Schema-Initialisierung (in @PostConstruct):**
|
||||
- Alle Services: `transaction { SchemaUtils.createMissingTablesAndColumns(...) }`
|
||||
- Gateway: `transaction { SchemaUtils.createMissingTablesAndColumns(...) }` für alle Kontexte
|
||||
**Schema Initialization (in @PostConstruct):**
|
||||
- All Services: `transaction { SchemaUtils.createMissingTablesAndColumns(...) }`
|
||||
- Gateway: `transaction { SchemaUtils.createMissingTablesAndColumns(...) }` for all contexts
|
||||
|
||||
**Business Logic Transaktionen:**
|
||||
- **TransactionalCreateHorseUseCase**: Verwendet `DatabaseFactory.dbQuery { ... }`
|
||||
- **DatabaseMigrator**: Verwendet `transaction { ... }` für Migrationen
|
||||
**Business Logic Transactions:**
|
||||
- **TransactionalCreateHorseUseCase**: Uses `DatabaseFactory.dbQuery { ... }`
|
||||
- **DatabaseMigrator**: Uses `transaction { ... }` for migrations
|
||||
|
||||
**Test-Transaktionen:**
|
||||
- SimpleDatabaseTest.kt: Direkte `transaction { ... }` Aufrufe in Tests
|
||||
**Test Transactions:**
|
||||
- SimpleDatabaseTest.kt: Direct `transaction { ... }` calls in tests
|
||||
|
||||
### ✅ Initialisierungsreihenfolge analysiert
|
||||
### ✅ Initialization Order Analyzed
|
||||
|
||||
**Korrekte Reihenfolge in Services:**
|
||||
**Correct Order in Services:**
|
||||
1. `@PostConstruct` → `DatabaseFactory.init(config)` → `Database.connect()`
|
||||
2. Sofort danach: `transaction { SchemaUtils.createMissingTablesAndColumns(...) }`
|
||||
3. Business Logic: `DatabaseFactory.dbQuery { ... }` für Transaktionen
|
||||
2. Immediately after: `transaction { SchemaUtils.createMissingTablesAndColumns(...) }`
|
||||
3. Business Logic: `DatabaseFactory.dbQuery { ... }` for transactions
|
||||
|
||||
**⚠️ PROBLEM - Gateway Initialisierung:**
|
||||
1. Ktor Application.configureDatabase() → direkter `Database.connect()`
|
||||
2. Sofort danach: `transaction { ... }` für alle Service-Schemas
|
||||
**⚠️ PROBLEM - Gateway Initialization:**
|
||||
1. Ktor Application.configureDatabase() → direct `Database.connect()`
|
||||
2. Immediately after: `transaction { ... }` for all service schemas
|
||||
|
||||
## 🚨 Identifizierte Probleme
|
||||
## 🚨 Identified Problems
|
||||
|
||||
### 1. **Inkonsistente Database.connect() Implementierung**
|
||||
- **Services**: Verwenden zentralen DatabaseFactory mit Connection Pooling
|
||||
- **Gateway**: Direkter Database.connect() ohne Connection Pooling
|
||||
- **Risiko**: Unterschiedliche Verbindungsqualität und -management
|
||||
### 1. **Inconsistent Database.connect() Implementation**
|
||||
- **Services**: Use central DatabaseFactory with Connection Pooling
|
||||
- **Gateway**: Direct Database.connect() without Connection Pooling
|
||||
- **Risk**: Different connection quality and management
|
||||
|
||||
### 2. **Potentielle Race Conditions**
|
||||
- Gateway und Services initialisieren unabhängig voneinander
|
||||
- Beide versuchen, Schemas für dieselben Tabellen zu erstellen
|
||||
- **Risiko**: Konflikte bei paralleler Initialisierung
|
||||
### 2. **Potential Race Conditions**
|
||||
- Gateway and services initialize independently
|
||||
- Both attempt to create schemas for the same tables
|
||||
- **Risk**: Conflicts during parallel initialization
|
||||
|
||||
### 3. **Verletzung der Separation of Concerns**
|
||||
- Gateway verwaltet Schemas für alle Services
|
||||
- Services verwalten ihre eigenen Schemas
|
||||
- **Risiko**: Doppelte Schema-Initialisierung
|
||||
### 3. **Violation of Separation of Concerns**
|
||||
- Gateway manages schemas for all services
|
||||
- Services manage their own schemas
|
||||
- **Risk**: Duplicate schema initialization
|
||||
|
||||
### 4. **Fehlende Initialisierungsreihenfolge-Garantien**
|
||||
- Keine explizite Abhängigkeitsreihenfolge zwischen Gateway und Services
|
||||
- **Risiko**: Exposed-Operationen vor Database.connect()
|
||||
### 4. **Missing Initialization Order Guarantees**
|
||||
- No explicit dependency order between Gateway and Services
|
||||
- **Risk**: Exposed operations before Database.connect()
|
||||
|
||||
## ✅ Empfehlungen
|
||||
## ✅ Recommendations
|
||||
|
||||
### 1. **Gateway auf DatabaseFactory umstellen**
|
||||
### 1. **Switch Gateway to DatabaseFactory**
|
||||
```kotlin
|
||||
// Statt direktem Database.connect():
|
||||
// Instead of direct Database.connect():
|
||||
fun Application.configureDatabase() {
|
||||
val config = DatabaseConfig.fromEnv() // oder aus Ktor Config
|
||||
val config = DatabaseConfig.fromEnv() // or from Ktor Config
|
||||
DatabaseFactory.init(config)
|
||||
// Schema-Initialisierung entfernen oder koordinieren
|
||||
// Remove or coordinate schema initialization
|
||||
}
|
||||
```
|
||||
|
||||
### 2. **Schema-Initialisierung koordinieren**
|
||||
**Option A**: Nur Services verwalten ihre Schemas (empfohlen)
|
||||
### 2. **Coordinate Schema Initialization**
|
||||
**Option A**: Only services manage their schemas (recommended)
|
||||
```kotlin
|
||||
// Gateway: Nur Verbindung, keine Schema-Initialisierung
|
||||
// Gateway: Only connection, no schema initialization
|
||||
fun Application.configureDatabase() {
|
||||
DatabaseFactory.init(DatabaseConfig.fromEnv())
|
||||
}
|
||||
```
|
||||
|
||||
**Option B**: Zentralisierte Schema-Verwaltung
|
||||
**Option B**: Centralized schema management
|
||||
```kotlin
|
||||
// Separater DatabaseSchemaInitializer mit @Order Annotation
|
||||
// Separate DatabaseSchemaInitializer with @Order annotation
|
||||
@Component
|
||||
@Order(Ordered.HIGHEST_PRECEDENCE)
|
||||
class DatabaseSchemaInitializer {
|
||||
@@ -106,9 +106,9 @@ class DatabaseSchemaInitializer {
|
||||
}
|
||||
```
|
||||
|
||||
### 3. **Startup-Reihenfolge sicherstellen**
|
||||
### 3. **Ensure Startup Order**
|
||||
```kotlin
|
||||
// Services mit @DependsOn
|
||||
// Services with @DependsOn
|
||||
@Configuration
|
||||
@DependsOn("databaseInitializer")
|
||||
class HorsesDatabaseConfiguration {
|
||||
@@ -116,9 +116,9 @@ class HorsesDatabaseConfiguration {
|
||||
}
|
||||
```
|
||||
|
||||
### 4. **Einheitliche Konfiguration**
|
||||
### 4. **Unified Configuration**
|
||||
```kotlin
|
||||
// Alle Komponenten verwenden DatabaseFactory
|
||||
// All components use DatabaseFactory
|
||||
class SomeService {
|
||||
suspend fun doSomething() {
|
||||
DatabaseFactory.dbQuery {
|
||||
@@ -128,21 +128,25 @@ class SomeService {
|
||||
}
|
||||
```
|
||||
|
||||
## 📋 Zusammenfassung
|
||||
## 📋 Summary
|
||||
|
||||
**✅ Korrekt implementiert:**
|
||||
- Alle Services verwenden proper @PostConstruct → Database.connect() → Exposed operations Reihenfolge
|
||||
- DatabaseFactory bietet robuste Connection Pool Konfiguration
|
||||
- Business Logic verwendet korrekte Transaktionsmuster
|
||||
**✅ Correctly implemented:**
|
||||
- All services use proper @PostConstruct → Database.connect() → Exposed operations sequence
|
||||
- DatabaseFactory provides robust Connection Pool configuration
|
||||
- Business logic uses correct transaction patterns
|
||||
|
||||
**⚠️ Zu beheben:**
|
||||
- Gateway Database.connect() Inkonsistenz
|
||||
- Potentielle Race Conditions bei Schema-Initialisierung
|
||||
- Fehlende Startup-Reihenfolge-Koordination
|
||||
**⚠️ To be fixed:**
|
||||
- Gateway Database.connect() inconsistency
|
||||
- Potential race conditions in schema initialization
|
||||
- Missing startup order coordination
|
||||
|
||||
**🎯 Priorität:**
|
||||
1. **Hoch**: Gateway auf DatabaseFactory umstellen
|
||||
2. **Mittel**: Schema-Initialisierung koordinieren
|
||||
3. **Niedrig**: Startup-Reihenfolge explizit definieren
|
||||
**🎯 Priority:**
|
||||
1. **High**: Switch Gateway to DatabaseFactory
|
||||
2. **Medium**: Coordinate schema initialization
|
||||
3. **Low**: Explicitly define startup order
|
||||
|
||||
Die Reihenfolge der Initialisierung ist grundsätzlich korrekt, aber die Inkonsistenz zwischen Gateway und Services sollte behoben werden, um potentielle Probleme zu vermeiden.
|
||||
The initialization sequence is fundamentally correct, but the inconsistency between Gateway and Services should be resolved to avoid potential problems.
|
||||
|
||||
---
|
||||
|
||||
*Last updated: July 25, 2025*
|
||||
|
||||
@@ -1,607 +0,0 @@
|
||||
# Entwicklungsanleitung - Erste Schritte
|
||||
|
||||
## Überblick
|
||||
|
||||
Diese Anleitung hilft neuen Entwicklern beim Einstieg in das Meldestelle-Projekt. Sie deckt alle notwendigen Schritte ab, von der initialen Einrichtung bis zur ersten erfolgreichen Entwicklungsumgebung.
|
||||
|
||||
## Voraussetzungen
|
||||
|
||||
### System-Anforderungen
|
||||
|
||||
- **Betriebssystem**: Windows 10+, macOS 10.15+, oder Linux (Ubuntu 20.04+ empfohlen)
|
||||
- **RAM**: Mindestens 8GB (16GB empfohlen)
|
||||
- **Speicher**: Mindestens 10GB freier Speicherplatz
|
||||
- **Netzwerk**: Stabile Internetverbindung für Downloads
|
||||
|
||||
### Erforderliche Software
|
||||
|
||||
#### 1. Java Development Kit (JDK)
|
||||
```bash
|
||||
# Java 21 installieren (empfohlen: Eclipse Temurin)
|
||||
# Windows (mit Chocolatey)
|
||||
choco install temurin21
|
||||
|
||||
# macOS (mit Homebrew)
|
||||
brew install --cask temurin21
|
||||
|
||||
# Linux (Ubuntu/Debian)
|
||||
sudo apt update
|
||||
sudo apt install openjdk-21-jdk
|
||||
|
||||
# Verifizierung
|
||||
java -version
|
||||
javac -version
|
||||
```
|
||||
|
||||
#### 2. Docker und Docker Compose
|
||||
```bash
|
||||
# Docker Desktop installieren (Windows/macOS)
|
||||
# Herunterladen von: https://www.docker.com/products/docker-desktop
|
||||
|
||||
# Linux (Ubuntu)
|
||||
sudo apt update
|
||||
sudo apt install docker.io docker-compose
|
||||
sudo usermod -aG docker $USER
|
||||
|
||||
# Verifizierung
|
||||
docker --version
|
||||
docker-compose --version
|
||||
```
|
||||
|
||||
#### 3. Git
|
||||
```bash
|
||||
# Windows (mit Chocolatey)
|
||||
choco install git
|
||||
|
||||
# macOS (mit Homebrew)
|
||||
brew install git
|
||||
|
||||
# Linux (Ubuntu)
|
||||
sudo apt install git
|
||||
|
||||
# Verifizierung
|
||||
git --version
|
||||
```
|
||||
|
||||
#### 4. IDE (Empfohlen: IntelliJ IDEA)
|
||||
```bash
|
||||
# IntelliJ IDEA Community Edition
|
||||
# Herunterladen von: https://www.jetbrains.com/idea/download/
|
||||
|
||||
# Oder mit Package Manager
|
||||
# Windows (Chocolatey)
|
||||
choco install intellijidea-community
|
||||
|
||||
# macOS (Homebrew)
|
||||
brew install --cask intellij-idea-ce
|
||||
|
||||
# Linux (Snap)
|
||||
sudo snap install intellij-idea-community --classic
|
||||
```
|
||||
|
||||
## Projekt-Setup
|
||||
|
||||
### 1. Repository klonen
|
||||
|
||||
```bash
|
||||
# Repository klonen
|
||||
git clone <repository-url>
|
||||
cd Meldestelle
|
||||
|
||||
# Branch-Status prüfen
|
||||
git status
|
||||
git branch -a
|
||||
```
|
||||
|
||||
### 2. Umgebungsvariablen konfigurieren
|
||||
|
||||
```bash
|
||||
# .env-Datei erstellen (falls nicht vorhanden)
|
||||
cp .env.example .env
|
||||
|
||||
# .env-Datei bearbeiten
|
||||
nano .env # oder mit bevorzugtem Editor
|
||||
```
|
||||
|
||||
#### Wichtige Umgebungsvariablen
|
||||
|
||||
```bash
|
||||
# Anwendungskonfiguration
|
||||
APP_ENVIRONMENT=development
|
||||
APP_NAME=meldestelle
|
||||
APP_VERSION=1.0.0
|
||||
|
||||
# Datenbank-Konfiguration
|
||||
DATABASE_URL=jdbc:postgresql://localhost:5432/meldestelle
|
||||
DATABASE_USERNAME=meldestelle
|
||||
DATABASE_PASSWORD=password
|
||||
|
||||
# Redis-Konfiguration
|
||||
REDIS_HOST=localhost
|
||||
REDIS_PORT=6379
|
||||
REDIS_PASSWORD=
|
||||
|
||||
# Keycloak-Konfiguration
|
||||
KEYCLOAK_URL=http://localhost:8080
|
||||
KEYCLOAK_REALM=meldestelle
|
||||
KEYCLOAK_CLIENT_ID=meldestelle-client
|
||||
|
||||
# Kafka-Konfiguration
|
||||
KAFKA_BOOTSTRAP_SERVERS=localhost:9092
|
||||
KAFKA_GROUP_ID=meldestelle-group
|
||||
```
|
||||
|
||||
### 3. Docker-Infrastruktur starten
|
||||
|
||||
```bash
|
||||
# Alle Services starten
|
||||
docker-compose up -d
|
||||
|
||||
# Status überprüfen
|
||||
docker-compose ps
|
||||
|
||||
# Logs anzeigen (optional)
|
||||
docker-compose logs -f
|
||||
|
||||
# Einzelne Services starten (falls gewünscht)
|
||||
docker-compose up -d postgres redis keycloak
|
||||
```
|
||||
|
||||
#### Service-Übersicht
|
||||
|
||||
| Service | Port | Beschreibung | URL |
|
||||
|---------|------|--------------|-----|
|
||||
| PostgreSQL | 5432 | Hauptdatenbank | localhost:5432 |
|
||||
| Redis | 6379 | Cache & Event Store | localhost:6379 |
|
||||
| Keycloak | 8080 | Authentifizierung | http://localhost:8080 |
|
||||
| Kafka | 9092 | Messaging | localhost:9092 |
|
||||
| Zookeeper | 2181 | Kafka Koordination | localhost:2181 |
|
||||
| Zipkin | 9411 | Distributed Tracing | http://localhost:9411 |
|
||||
| Prometheus | 9090 | Metriken | http://localhost:9090 |
|
||||
| Grafana | 3000 | Dashboards | http://localhost:3000 |
|
||||
|
||||
### 4. Umgebung validieren
|
||||
|
||||
```bash
|
||||
# Validierungsskript ausführen
|
||||
./validate-env.sh
|
||||
|
||||
# Oder manuell prüfen
|
||||
docker-compose ps
|
||||
curl http://localhost:8080/auth/realms/meldestelle
|
||||
```
|
||||
|
||||
## IDE-Konfiguration
|
||||
|
||||
### IntelliJ IDEA Setup
|
||||
|
||||
#### 1. Projekt öffnen
|
||||
1. IntelliJ IDEA starten
|
||||
2. "Open" wählen
|
||||
3. Meldestelle-Projektverzeichnis auswählen
|
||||
4. "Open as Project" bestätigen
|
||||
|
||||
#### 2. Kotlin-Plugin aktivieren
|
||||
1. File → Settings (Ctrl+Alt+S)
|
||||
2. Plugins → Marketplace
|
||||
3. "Kotlin" suchen und installieren
|
||||
4. IDE neu starten
|
||||
|
||||
#### 3. Gradle-Konfiguration
|
||||
1. File → Settings → Build → Gradle
|
||||
2. "Use Gradle from" → "gradle-wrapper.properties file"
|
||||
3. "Gradle JVM" → Java 21 auswählen
|
||||
4. "Apply" und "OK"
|
||||
|
||||
#### 4. Code-Style konfigurieren
|
||||
1. File → Settings → Editor → Code Style
|
||||
2. Scheme → "Project" auswählen
|
||||
3. Kotlin → Tabs and Indents:
|
||||
- Tab size: 4
|
||||
- Indent: 4
|
||||
- Continuation indent: 8
|
||||
|
||||
#### 5. Nützliche Plugins installieren
|
||||
- **Docker**: Docker-Integration
|
||||
- **Database Tools**: Datenbankzugriff
|
||||
- **GitToolBox**: Erweiterte Git-Features
|
||||
- **Rainbow Brackets**: Bessere Klammer-Visualisierung
|
||||
- **String Manipulation**: Text-Utilities
|
||||
|
||||
### VS Code Setup (Alternative)
|
||||
|
||||
#### 1. Erforderliche Extensions
|
||||
```bash
|
||||
# Extension Pack for Java
|
||||
code --install-extension vscjava.vscode-java-pack
|
||||
|
||||
# Kotlin Language
|
||||
code --install-extension fwcd.kotlin
|
||||
|
||||
# Docker
|
||||
code --install-extension ms-azuretools.vscode-docker
|
||||
|
||||
# GitLens
|
||||
code --install-extension eamodio.gitlens
|
||||
```
|
||||
|
||||
#### 2. Workspace-Konfiguration
|
||||
```json
|
||||
{
|
||||
"java.home": "/path/to/java-21",
|
||||
"java.configuration.updateBuildConfiguration": "automatic",
|
||||
"kotlin.languageServer.enabled": true,
|
||||
"docker.showStartPage": false
|
||||
}
|
||||
```
|
||||
|
||||
Erstellen Sie diese Datei als `.vscode/settings.json` im Projektverzeichnis.
|
||||
|
||||
## Projekt-Architektur verstehen
|
||||
|
||||
### Modulare Struktur
|
||||
|
||||
```
|
||||
Meldestelle/
|
||||
├── core/ # Shared Kernel
|
||||
│ ├── core-domain/ # Gemeinsame Domain-Modelle
|
||||
│ └── core-utils/ # Utilities und Konfiguration
|
||||
├── members/ # Mitgliederverwaltung
|
||||
│ ├── members-domain/ # Domain Layer
|
||||
│ ├── members-application/ # Application Layer
|
||||
│ ├── members-infrastructure/ # Infrastructure Layer
|
||||
│ ├── members-api/ # API Layer
|
||||
│ └── members-service/ # Service Layer
|
||||
├── horses/ # Pferderegistrierung
|
||||
├── events/ # Veranstaltungsverwaltung
|
||||
├── masterdata/ # Stammdatenverwaltung
|
||||
├── infrastructure/ # Infrastruktur-Services
|
||||
├── client/ # Client-Anwendungen
|
||||
└── docs/ # Dokumentation
|
||||
```
|
||||
|
||||
### Clean Architecture Prinzipien
|
||||
|
||||
1. **Domain Layer**: Geschäftslogik und Entitäten
|
||||
2. **Application Layer**: Use Cases und Orchestrierung
|
||||
3. **Infrastructure Layer**: Datenbankzugriff und externe Services
|
||||
4. **API Layer**: REST-Controller und DTOs
|
||||
5. **Service Layer**: Spring Boot Anwendungen
|
||||
|
||||
### Technologie-Stack
|
||||
|
||||
- **Backend**: Kotlin + Spring Boot
|
||||
- **Datenbank**: PostgreSQL + Exposed ORM
|
||||
- **Caching**: Redis
|
||||
- **Messaging**: Apache Kafka
|
||||
- **Authentifizierung**: Keycloak + JWT
|
||||
- **Monitoring**: Prometheus + Grafana
|
||||
- **Tracing**: Zipkin
|
||||
- **Frontend**: Jetpack Compose (Desktop/Web)
|
||||
- **Build**: Gradle mit Kotlin DSL
|
||||
|
||||
## Erste Entwicklungsschritte
|
||||
|
||||
### 1. Projekt kompilieren
|
||||
|
||||
```bash
|
||||
# Vollständigen Build ausführen
|
||||
./gradlew build
|
||||
|
||||
# Nur kompilieren (ohne Tests)
|
||||
./gradlew compileKotlin
|
||||
|
||||
# Spezifisches Modul kompilieren
|
||||
./gradlew :members:members-service:build
|
||||
```
|
||||
|
||||
### 2. Tests ausführen
|
||||
|
||||
```bash
|
||||
# Alle Tests
|
||||
./gradlew test
|
||||
|
||||
# Modul-spezifische Tests
|
||||
./gradlew :members:test
|
||||
|
||||
# Integration Tests
|
||||
./gradlew integrationTest
|
||||
|
||||
# Test-Reports anzeigen
|
||||
open build/reports/tests/test/index.html
|
||||
```
|
||||
|
||||
### 3. Services starten
|
||||
|
||||
```bash
|
||||
# Einzelnen Service starten
|
||||
./gradlew :members:members-service:bootRun
|
||||
|
||||
# Mit spezifischem Profil
|
||||
./gradlew :members:members-service:bootRun --args='--spring.profiles.active=dev'
|
||||
|
||||
# API Gateway starten
|
||||
./gradlew :infrastructure:gateway:bootRun
|
||||
```
|
||||
|
||||
### 4. Datenbank-Migrationen
|
||||
|
||||
```bash
|
||||
# Flyway-Migrationen ausführen
|
||||
./gradlew flywayMigrate
|
||||
|
||||
# Migration-Status prüfen
|
||||
./gradlew flywayInfo
|
||||
|
||||
# Datenbank zurücksetzen (Vorsicht!)
|
||||
./gradlew flywayClean
|
||||
```
|
||||
|
||||
## Entwicklungsworkflows
|
||||
|
||||
### Feature-Entwicklung
|
||||
|
||||
#### 1. Feature Branch erstellen
|
||||
```bash
|
||||
# Neuen Feature Branch erstellen
|
||||
git checkout -b feature/neue-funktion
|
||||
|
||||
# Branch auf Remote pushen
|
||||
git push -u origin feature/neue-funktion
|
||||
```
|
||||
|
||||
#### 2. Code-Änderungen
|
||||
```bash
|
||||
# Änderungen committen
|
||||
git add .
|
||||
git commit -m "feat: neue Funktion implementiert"
|
||||
|
||||
# Code-Style prüfen
|
||||
./gradlew ktlintCheck
|
||||
|
||||
# Code formatieren
|
||||
./gradlew ktlintFormat
|
||||
```
|
||||
|
||||
#### 3. Tests und Qualitätssicherung
|
||||
```bash
|
||||
# Tests ausführen
|
||||
./gradlew test
|
||||
|
||||
# Code-Coverage prüfen
|
||||
./gradlew jacocoTestReport
|
||||
open build/reports/jacoco/test/html/index.html
|
||||
|
||||
# Statische Code-Analyse
|
||||
./gradlew detekt
|
||||
```
|
||||
|
||||
#### 4. Pull Request erstellen
|
||||
1. Änderungen auf Remote Branch pushen
|
||||
2. Pull Request im Repository erstellen
|
||||
3. Code Review abwarten
|
||||
4. Nach Approval mergen
|
||||
|
||||
### Debugging
|
||||
|
||||
#### 1. Service-Debugging
|
||||
```bash
|
||||
# Service mit Debug-Port starten
|
||||
./gradlew :members:members-service:bootRun --debug-jvm
|
||||
|
||||
# Oder mit spezifischem Port
|
||||
./gradlew :members:members-service:bootRun -Dspring-boot.run.jvmArguments="-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5005"
|
||||
```
|
||||
|
||||
#### 2. IntelliJ Remote Debugging
|
||||
1. Run → Edit Configurations
|
||||
2. "+" → Remote JVM Debug
|
||||
3. Port: 5005 (oder gewählter Port)
|
||||
4. Debug-Session starten
|
||||
|
||||
#### 3. Logs analysieren
|
||||
```bash
|
||||
# Service-Logs anzeigen
|
||||
docker-compose logs -f members-service
|
||||
|
||||
# Alle Logs
|
||||
docker-compose logs -f
|
||||
|
||||
# Spezifische Log-Level
|
||||
export LOGGING_LEVEL_ROOT=DEBUG
|
||||
./gradlew :members:members-service:bootRun
|
||||
```
|
||||
|
||||
### API-Testing
|
||||
|
||||
#### 1. Swagger UI verwenden
|
||||
```bash
|
||||
# Service starten
|
||||
./gradlew :members:members-service:bootRun
|
||||
|
||||
# Swagger UI öffnen
|
||||
open http://localhost:8082/swagger-ui.html
|
||||
```
|
||||
|
||||
#### 2. cURL-Beispiele
|
||||
```bash
|
||||
# Alle Mitglieder abrufen
|
||||
curl -H "Authorization: Bearer <token>" \
|
||||
http://localhost:8082/api/members
|
||||
|
||||
# Neues Mitglied erstellen
|
||||
curl -X POST \
|
||||
-H "Content-Type: application/json" \
|
||||
-H "Authorization: Bearer <token>" \
|
||||
-d '{"firstName":"Max","lastName":"Mustermann","email":"max@example.com","membershipNumber":"M2024001","membershipStartDate":"2024-01-01"}' \
|
||||
http://localhost:8082/api/members
|
||||
```
|
||||
|
||||
#### 3. Postman Collections
|
||||
```bash
|
||||
# Postman Collections importieren
|
||||
# Dateien in docs/postman/ verwenden
|
||||
```
|
||||
|
||||
## Häufige Probleme und Lösungen
|
||||
|
||||
### Docker-Probleme
|
||||
|
||||
#### Services starten nicht
|
||||
```bash
|
||||
# Ports prüfen
|
||||
netstat -tulpn | grep :5432
|
||||
|
||||
# Docker-Logs prüfen
|
||||
docker-compose logs postgres
|
||||
|
||||
# Services neu starten
|
||||
docker-compose down
|
||||
docker-compose up -d
|
||||
```
|
||||
|
||||
#### Speicherplatz-Probleme
|
||||
```bash
|
||||
# Nicht verwendete Images entfernen
|
||||
docker system prune -a
|
||||
|
||||
# Volumes aufräumen
|
||||
docker volume prune
|
||||
```
|
||||
|
||||
### Build-Probleme
|
||||
|
||||
#### Gradle-Cache-Probleme
|
||||
```bash
|
||||
# Gradle-Cache löschen
|
||||
./gradlew clean
|
||||
rm -rf ~/.gradle/caches
|
||||
|
||||
# Dependencies neu laden
|
||||
./gradlew build --refresh-dependencies
|
||||
```
|
||||
|
||||
#### Kotlin-Compiler-Probleme
|
||||
```bash
|
||||
# Kotlin-Daemon stoppen
|
||||
./gradlew --stop
|
||||
|
||||
# Build-Verzeichnis löschen
|
||||
./gradlew clean
|
||||
|
||||
# Neu kompilieren
|
||||
./gradlew build
|
||||
```
|
||||
|
||||
### Datenbank-Probleme
|
||||
|
||||
#### Verbindungsfehler
|
||||
```bash
|
||||
# PostgreSQL-Status prüfen
|
||||
docker-compose ps postgres
|
||||
|
||||
# Datenbank-Logs prüfen
|
||||
docker-compose logs postgres
|
||||
|
||||
# Verbindung testen
|
||||
psql -h localhost -p 5432 -U meldestelle -d meldestelle
|
||||
```
|
||||
|
||||
#### Migration-Fehler
|
||||
```bash
|
||||
# Migration-Status prüfen
|
||||
./gradlew flywayInfo
|
||||
|
||||
# Fehlgeschlagene Migration reparieren
|
||||
./gradlew flywayRepair
|
||||
|
||||
# Datenbank zurücksetzen (Entwicklung)
|
||||
docker-compose down -v
|
||||
docker-compose up -d postgres
|
||||
./gradlew flywayMigrate
|
||||
```
|
||||
|
||||
## Nützliche Befehle
|
||||
|
||||
### Gradle-Tasks
|
||||
```bash
|
||||
# Alle verfügbaren Tasks anzeigen
|
||||
./gradlew tasks
|
||||
|
||||
# Abhängigkeiten anzeigen
|
||||
./gradlew dependencies
|
||||
|
||||
# Projekt-Informationen
|
||||
./gradlew projects
|
||||
|
||||
# Build-Scan erstellen
|
||||
./gradlew build --scan
|
||||
```
|
||||
|
||||
### Docker-Befehle
|
||||
```bash
|
||||
# Container-Status
|
||||
docker-compose ps
|
||||
|
||||
# Logs verfolgen
|
||||
docker-compose logs -f [service-name]
|
||||
|
||||
# Container neu starten
|
||||
docker-compose restart [service-name]
|
||||
|
||||
# In Container einloggen
|
||||
docker-compose exec postgres psql -U meldestelle
|
||||
```
|
||||
|
||||
### Git-Workflows
|
||||
```bash
|
||||
# Aktuellen Status prüfen
|
||||
git status
|
||||
|
||||
# Änderungen stagen
|
||||
git add .
|
||||
|
||||
# Commit mit konventioneller Nachricht
|
||||
git commit -m "feat(members): neue Validierung hinzugefügt"
|
||||
|
||||
# Branch wechseln
|
||||
git checkout main
|
||||
git pull origin main
|
||||
```
|
||||
|
||||
## Weiterführende Ressourcen
|
||||
|
||||
### Dokumentation
|
||||
- [API-Dokumentation](../api/README.md)
|
||||
- [Architektur-Dokumentation](../architecture/)
|
||||
- [Deployment-Anleitung](../README-PRODUCTION.md)
|
||||
|
||||
### Externe Ressourcen
|
||||
- [Kotlin-Dokumentation](https://kotlinlang.org/docs/)
|
||||
- [Spring Boot-Dokumentation](https://spring.io/projects/spring-boot)
|
||||
- [Docker-Dokumentation](https://docs.docker.com/)
|
||||
- [PostgreSQL-Dokumentation](https://www.postgresql.org/docs/)
|
||||
|
||||
### Community und Support
|
||||
- **Issue Tracker**: GitHub Issues
|
||||
- **Diskussionen**: GitHub Discussions
|
||||
- **Code Reviews**: Pull Requests
|
||||
- **Dokumentation**: Wiki
|
||||
|
||||
## Nächste Schritte
|
||||
|
||||
Nach erfolgreichem Setup:
|
||||
|
||||
1. **Code-Basis erkunden**: Beginnen Sie mit dem `members`-Modul
|
||||
2. **Tests ausführen**: Verstehen Sie die Test-Struktur
|
||||
3. **Erste Änderung**: Implementieren Sie eine kleine Verbesserung
|
||||
4. **Code Review**: Erstellen Sie einen Pull Request
|
||||
5. **Dokumentation**: Erweitern Sie die Dokumentation
|
||||
|
||||
---
|
||||
|
||||
**Letzte Aktualisierung**: 25. Juli 2025
|
||||
**Version**: 1.0
|
||||
**Zielgruppe**: Neue Entwickler
|
||||
|
||||
Bei Fragen oder Problemen erstellen Sie bitte ein Issue im Repository oder wenden Sie sich an das Entwicklungsteam.
|
||||
@@ -0,0 +1,53 @@
|
||||
---
|
||||
owner: ops-team
|
||||
status: active
|
||||
review_cycle: 180d
|
||||
last_reviewed: 2025-10-15
|
||||
summary: Anleitung zur Installation und Konfiguration des Nginx Reverse Proxys auf dem Proxmox-Host für die Meldestelle-Services.
|
||||
---
|
||||
|
||||
# How-To: Proxmox/Nginx Reverse Proxy deployen
|
||||
|
||||
Diese Anleitung beschreibt die Einrichtung des Nginx Reverse Proxys auf dem Proxmox-Host. Die Beispielkonfiguration liegt im Repository und wird unverändert übernommen.
|
||||
|
||||
- Beispielkonfiguration: proxmox-nginx/meldestelle.conf
|
||||
|
||||
## Voraussetzungen
|
||||
- Proxmox-Host mit root-/sudo-Zugang
|
||||
- Installiertes Nginx (`apt install nginx`)
|
||||
- Lokale Container-Services laufen auf dem Host und sind über `localhost` erreichbar (Web 4000, Gateway 8081, VNC 6080)
|
||||
|
||||
## Schritte
|
||||
1) Konfigurationsdatei auf den Host kopieren
|
||||
```bash
|
||||
sudo cp docs/proxmox-nginx/meldestelle.conf /etc/nginx/sites-available/
|
||||
```
|
||||
|
||||
2) Site aktivieren (Symlink anlegen)
|
||||
```bash
|
||||
sudo ln -s /etc/nginx/sites-available/meldestelle.conf /etc/nginx/sites-enabled/
|
||||
```
|
||||
|
||||
3) Nginx Konfiguration testen und neu laden
|
||||
```bash
|
||||
sudo nginx -t && sudo systemctl reload nginx
|
||||
```
|
||||
|
||||
4) DNS konfigurieren (Beispiele)
|
||||
- meldestelle.yourdomain.com → öffentliche IP deines Proxmox-Hosts
|
||||
- api.meldestelle.yourdomain.com → öffentliche IP deines Proxmox-Hosts
|
||||
- vnc.meldestelle.yourdomain.com → öffentliche IP deines Proxmox-Hosts
|
||||
|
||||
5) Health-Checks
|
||||
```bash
|
||||
curl -i http://api.meldestelle.yourdomain.com/actuator/health
|
||||
curl -i http://meldestelle.yourdomain.com/health
|
||||
```
|
||||
|
||||
## HTTPS (optional)
|
||||
In der Beispielkonfiguration sind HTTPS-Serverblöcke und HTTP→HTTPS Redirects als Kommentar enthalten. Aktiviere diese Blöcke, wenn du Zertifikate (Let's Encrypt/Cloudflare) eingerichtet hast. Datei: proxmox-nginx/meldestelle.conf
|
||||
|
||||
## Fehlerbehebung
|
||||
- 502 Bad Gateway: Zielcontainer läuft nicht oder Port falsch → Dienste starten (`make full-up`) und Ports prüfen.
|
||||
- CORS-Fehler: API ausschließlich über die `api.*`-Domain aufrufen; Web-App über `meldestelle.*`.
|
||||
- Änderungen ohne Effekt: `nginx -t` ausführen und `systemctl reload nginx`.
|
||||
@@ -0,0 +1,67 @@
|
||||
---
|
||||
owner: project-maintainers
|
||||
status: active
|
||||
review_cycle: 90d
|
||||
last_reviewed: 2025-10-15
|
||||
summary: Kürzeste Anleitung, um das komplette System lokal zu starten und zu prüfen, ob alles läuft.
|
||||
---
|
||||
|
||||
# How-To: Lokale Umgebung starten (Quickstart)
|
||||
|
||||
Diese Kurz-Anleitung bringt deine lokale Umgebung in wenigen Minuten zum Laufen.
|
||||
|
||||
## Starten
|
||||
- Komplettes System (Infra + Services + Clients)
|
||||
```bash
|
||||
make full-up
|
||||
```
|
||||
|
||||
- Nur Backend (Infra + Gateway + Microservices)
|
||||
```bash
|
||||
make services-up
|
||||
```
|
||||
|
||||
- Nur Clients (Infra + Web-App)
|
||||
```bash
|
||||
make clients-up
|
||||
```
|
||||
|
||||
Logs ansehen (z. B. Backend):
|
||||
```bash
|
||||
make services-logs
|
||||
```
|
||||
|
||||
## Wichtige URLs
|
||||
- Web App: http://localhost:4000
|
||||
- API Gateway: http://localhost:8081 (Health: /actuator/health)
|
||||
- Keycloak (Auth): http://localhost:8180
|
||||
- Consul (Service Discovery): http://localhost:8500
|
||||
|
||||
Weitere Ports findest du unter: reference/ports-and-urls.md
|
||||
|
||||
## Health-Checks
|
||||
```bash
|
||||
# Gateway
|
||||
curl -i http://localhost:8081/actuator/health
|
||||
|
||||
# Web-App (falls vorhanden)
|
||||
curl -i http://localhost:4000/health || true
|
||||
```
|
||||
|
||||
## Auth (Keycloak)
|
||||
- Admin-Login (default): http://localhost:8180
|
||||
- Username: KC_BOOTSTRAP_ADMIN_USERNAME (default: admin)
|
||||
- Password: KC_BOOTSTRAP_ADMIN_PASSWORD (default: admin)
|
||||
- Beim ersten Start wird der Realm aus docker/services/keycloak/meldestelle-realm.json importiert.
|
||||
|
||||
## Häufige Probleme
|
||||
- Dienste nicht erreichbar → Containers laufen? `make full-logs` bzw. `make services-logs` prüfen.
|
||||
- 401/403 beim API-Aufruf → Prüfen, ob ein gültiges Bearer-Token gesendet wird und Keycloak erreichbar ist.
|
||||
- CORS im Browser → API über das Gateway (http://localhost:8081) aufrufen und nicht direkt die Services (8082–8086).
|
||||
- Port-Kollisionen → Belegte Ports mit `lsof -i :PORT` prüfen oder Ports anpassen.
|
||||
|
||||
## Stoppen
|
||||
```bash
|
||||
make full-down
|
||||
# oder spezifisch: make services-down / make clients-down / make infrastructure-down
|
||||
```
|
||||
-6388
File diff suppressed because one or more lines are too long
@@ -0,0 +1,26 @@
|
||||
---
|
||||
owner: project-maintainers
|
||||
status: active
|
||||
review_cycle: 90d
|
||||
last_reviewed: 2025-10-15
|
||||
summary: Schlanker Einstiegspunkt in die Dokumentation der Meldestelle. Nur die wichtigsten Links für Start, Überblick, API, Produktion und aktuelles Vorhaben.
|
||||
---
|
||||
|
||||
# Meldestelle – Dokumentation (Startseite)
|
||||
|
||||
Willkommen! Das ist der zentrale Einstieg in die Projektdokumentation. Starte hier.
|
||||
|
||||
## Start
|
||||
- Schnellstart lokal: how-to/start-local.md
|
||||
- Gesamtüberblick: overview/system-overview.md
|
||||
|
||||
## API
|
||||
- API-Übersicht: api/README.md
|
||||
|
||||
## Betrieb
|
||||
- Produktion (Proxmox/Nginx): how-to/deploy-proxmox-nginx.md
|
||||
|
||||
## Aktuelles Vorhaben
|
||||
- Now-Page: now/current.md
|
||||
|
||||
Hinweis: Diese Seite ist der einzige offizielle Einstiegspunkt. Ältere Indizes (z. B. INDEX.md oder bilingualer Index) sind historisch bzw. entfernt.
|
||||
@@ -0,0 +1,31 @@
|
||||
---
|
||||
owner: project-maintainers
|
||||
status: active
|
||||
last_reviewed: 2025-10-15
|
||||
review_cycle: 90d
|
||||
summary: Anleitung zur Nutzung der Now-Page (Initiativen-One‑Pager) als zentraler Steuerungs- und Übersichtspunkt.
|
||||
---
|
||||
|
||||
# Now-Page – Nutzung & Workflow
|
||||
|
||||
Die Now-Page ist ein schlanker One‑Pager für dein aktuelles Vorhaben. Sie beantwortet stets fünf Fragen: Was, Warum, Wie, Was ist zu tun, und Was ist als Nächstes dran.
|
||||
|
||||
## Struktur
|
||||
- Aktive Seite: `docs/now/current.md`
|
||||
- Vorlage: `docs/now/TEMPLATE.md`
|
||||
- Archiv (optional): `docs/now/archive/` (einfach Dateien hinein verschieben)
|
||||
|
||||
## So verwendest du die Now-Page
|
||||
1. Neue Initiative starten: Kopiere `TEMPLATE.md` nach `current.md` und fülle sie aus.
|
||||
2. Kurz halten: 1 Seite, maximal 5–10 Tasks. Große Aufgaben in kleinere Schneiden.
|
||||
3. Pflege-Ritual: Bei Änderung von Fokus/Status/Plan kurz aktualisieren, `last_reviewed` anpassen.
|
||||
4. Abschluss: `status: done` setzen, 3 Bulletpoints „Lessons Learned“ ergänzen und Datei nach `now/archive/` verschieben.
|
||||
5. Dauerhafte Entscheidungen: Als ADR in `docs/architecture/adr/` festhalten und aus der Now‑Page verlinken.
|
||||
|
||||
## Tipps
|
||||
- Verlinke nur, was du beim Arbeiten wirklich brauchst (PRs, Issues, wichtige How‑Tos).
|
||||
- Nutze die Now‑Page als Daily/Nächstes‑To‑Do‑Quelle statt vieler verstreuter Notizen.
|
||||
- Optional in CI: Einen „Stale‑Check“ einführen, der warnt, wenn `current.md` länger als `review_cycle` nicht aktualisiert wurde.
|
||||
|
||||
## Navigation
|
||||
- Die Startseite (docs/index.md) verlinkt direkt auf `now/current.md`, damit du jederzeit mit einem Klick am aktuellen Fokus bist.
|
||||
@@ -0,0 +1,39 @@
|
||||
---
|
||||
owner: <dein-name-oder-team>
|
||||
status: active # active | blocked | done
|
||||
timeframe: YYYY-MM-DD → YYYY-MM-DD
|
||||
last_reviewed: YYYY-MM-DD
|
||||
review_cycle: 7d # erinnert dich wöchentlich ans Aktualisieren
|
||||
summary: One-Pager-Template für das aktuell wichtigste Vorhaben (Now-Page).
|
||||
---
|
||||
|
||||
# Aktuelle Initiative: <Titel>
|
||||
|
||||
## 1) Vision (Was?)
|
||||
Ein Satz Zielbild. Was soll am Ende anders/besser sein? Optional: In/Out of Scope.
|
||||
- In Scope: …
|
||||
- Out of Scope: …
|
||||
|
||||
## 2) Why (Warum so?)
|
||||
Problem, Zielmetriken/Erfolgskriterien, Alternativen/Trade-offs.
|
||||
- Erfolg messbar an: <Metriken/Kriterien>
|
||||
- Falls dauerhaft relevant: verweise auf ADR (`docs/adr/...`).
|
||||
|
||||
## 3) How (Wie umsetzen?)
|
||||
Kurzarchitektur, Ansatz, Risiken/Abhängigkeiten. 5–10 Zeilen genügen.
|
||||
- Ansatz: …
|
||||
- Risiken: …
|
||||
- Abhängigkeiten: …
|
||||
|
||||
## 4) Plan (Was ist jetzt zu tun?)
|
||||
Milestones + nächste konkrete Schritte. Max. 5–10 Tasks, sonst zu groß schneiden.
|
||||
- [ ] Schritt 1 (heute)
|
||||
- [ ] Schritt 2 (diese Woche)
|
||||
- [ ] Schritt 3 (nächste Woche)
|
||||
|
||||
## 5) Status & Nächster Fokus
|
||||
- Status: active | blocked | done
|
||||
- Nächster Fokus (heute): <1–2 Sätze>
|
||||
|
||||
## 6) Referenzen
|
||||
Links zu PRs, Issues, Diagrammen, Konfigs (nur die, die man wirklich braucht).
|
||||
@@ -0,0 +1,43 @@
|
||||
---
|
||||
owner: stefan
|
||||
status: active
|
||||
timeframe: 2025-10-15 → 2025-10-29
|
||||
last_reviewed: 2025-10-15
|
||||
review_cycle: 7d
|
||||
summary: Minimal‑Doku + Now‑Page etablieren, um Übersicht zurückzugewinnen.
|
||||
---
|
||||
|
||||
# Aktuelle Initiative: Doku verschlanken & Now‑Page einführen
|
||||
|
||||
## 1) Vision (Was?)
|
||||
Eine verlässliche, minimale Doku (≤5 Seiten) + ein stets aktueller One‑Pager für das laufende Vorhaben.
|
||||
- In Scope: Start/Overview/API/Prod-HowTo/Now-Page
|
||||
- Out of Scope: Vollständige Übersetzungen, alte Berichte/Prosa
|
||||
|
||||
## 2) Why (Warum so?)
|
||||
Zu viele, verstreute Dokumente erzeugen Drift und Entscheidungsunsicherheit. Ziel: Orientierung in <2 Min. wiederfinden.
|
||||
- Erfolg messbar an: 1 Einstiegspunkt, 0 Broken Links, Validierung grün
|
||||
- Dauerhaft relevante Entscheidungen künftig als ADR, aus Now‑Page verlinkt
|
||||
|
||||
## 3) How (Wie umsetzen?)
|
||||
- Behalten: `docs/index.md`, `overview/system-overview.md`, `how-to/*`, `api/README.md`, `now/current.md`
|
||||
- Entfernen/Archivieren: `Tagebuch/`, alte Indizes
|
||||
- CI beibehalten (Link‑Check optional), später Stale‑Check für Now‑Page ergänzen
|
||||
|
||||
## 4) Plan (Was ist jetzt zu tun?)
|
||||
- [ ] Index minimalisieren und nur auf Kernseiten verlinken
|
||||
- [ ] System Overview anlegen und Ports/Health bündeln
|
||||
- [ ] Now‑Page Template + current.md erstellen
|
||||
- [ ] Alte Indizes und Tagebuch entfernen
|
||||
- [ ] Validierung laufen lassen und etwaige Links reparieren
|
||||
- [ ] Nächste Initiative vorbereiten: Git‑Flow & GitHub Actions Strategy
|
||||
|
||||
## 5) Status & Nächster Fokus
|
||||
- Status: active
|
||||
- Nächster Fokus: Validierung ausführen und offene Link‑Themen bereinigen; danach Git‑Flow/GitHub‑Actions planen
|
||||
|
||||
## 6) Referenzen
|
||||
- Start lokal: `docs/how-to/start-local.md`
|
||||
- Übersicht: `docs/overview/system-overview.md`
|
||||
- Produktion/Nginx: `docs/how-to/deploy-proxmox-nginx.md`
|
||||
- API: `docs/api/README.md`
|
||||
@@ -0,0 +1,79 @@
|
||||
---
|
||||
owner: project-owner
|
||||
status: active
|
||||
last_reviewed: 2025-10-15
|
||||
review_cycle: 90d
|
||||
summary: Gesamtüberblick – Was ist vorhanden, wie funktioniert es, wie starte/deploye ich es.
|
||||
---
|
||||
|
||||
# Meldestelle – System Overview (Kurz & vollständig)
|
||||
|
||||
## Was ist vorhanden (Bausteine)
|
||||
- Clients
|
||||
- Web App (Port 4000)
|
||||
- optional Desktop/noVNC (Port 6080)
|
||||
- Gateway & Services
|
||||
- API Gateway (Spring Cloud Gateway, Port 8081)
|
||||
- Microservices: Members (8083), Horses (8084), Events (8085), Masterdata (8086), Ping (8082)
|
||||
- Infrastruktur
|
||||
- Postgres (5432), Redis (6379), Keycloak (8180), Consul (8500)
|
||||
- Reverse Proxy (Produktion)
|
||||
- Nginx auf Proxmox-Host
|
||||
- vHosts: `meldestelle.yourdomain.com` (Web), `api.meldestelle.yourdomain.com` (API), `vnc.meldestelle.yourdomain.com` (VNC)
|
||||
|
||||
## Wie funktioniert es (Ablauf & Verantwortungen)
|
||||
- Einstieg nur über das API-Gateway (Security, CORS, Rate-Limits, Observability, Routing)
|
||||
- Authentifizierung via Keycloak (OIDC/JWT)
|
||||
- Web holt Token bei Keycloak → sendet Requests mit `Authorization: Bearer <JWT>`
|
||||
- Gateway validiert JWT (JWKs), injiziert Kontext, routet an Services
|
||||
- Service Discovery über Consul (Gateway ↔ Services)
|
||||
- Persistenz: Services schreiben/lesen in Postgres; Redis optional für Cache
|
||||
- Produktion: Öffentliche Zugriffe laufen über Nginx-vHosts → Gateway/Web/noVNC in Docker
|
||||
|
||||
## Starten & Stoppen (lokal)
|
||||
- Komplettes System: `make full-up`
|
||||
- Nur Infrastruktur: `make infrastructure-up`
|
||||
- Nur Backend (inkl. Gateway): `make services-up`
|
||||
- Nur Clients (inkl. Web): `make clients-up`
|
||||
- Stoppen: `make full-down` (bzw. `*-down`)
|
||||
- Logs: `make full-logs` (bzw. `services-logs`, `infrastructure-logs`)
|
||||
|
||||
## Health, URLs & Ports
|
||||
- Web: `http://localhost:4000` → Health: `/health`
|
||||
- Gateway: `http://localhost:8081` → Health: `/actuator/health`
|
||||
- Services (dev): Ping 8082, Members 8083, Horses 8084, Events 8085, Masterdata 8086
|
||||
- Keycloak: `http://localhost:8180`
|
||||
- Consul UI: `http://localhost:8500`
|
||||
- Postgres: `localhost:5432`
|
||||
- Redis: `localhost:6379`
|
||||
- noVNC: `http://localhost:6080`
|
||||
|
||||
## Auth-Flow (kurz)
|
||||
1. Web ruft geschützte Seite → Redirect zu Keycloak `/authorize`
|
||||
2. Login → Code → Token-Tausch (ID/Access Token)
|
||||
3. Web ruft Gateway mit `Bearer <JWT>` auf → Gateway prüft Token → leitet an Service
|
||||
|
||||
## Produktion (Proxmox/Nginx)
|
||||
- Datei: `docs/proxmox-nginx/meldestelle.conf`
|
||||
- vHosts:
|
||||
- `meldestelle.yourdomain.com` → Web (`localhost:4000`)
|
||||
- `api.meldestelle.yourdomain.com` → Gateway (`localhost:8081`)
|
||||
- `vnc.meldestelle.yourdomain.com` → noVNC (`localhost:6080`)
|
||||
- Health-Checks:
|
||||
- `curl -i http://api.meldestelle.yourdomain.com/actuator/health`
|
||||
- `curl -i http://meldestelle.yourdomain.com/health`
|
||||
|
||||
## Konfiguration auf einen Blick (Defaults)
|
||||
- Postgres: `POSTGRES_USER=meldestelle`, `POSTGRES_PASSWORD=meldestelle`, `POSTGRES_DB=meldestelle`
|
||||
- Keycloak Admin: `KC_BOOTSTRAP_ADMIN_USERNAME=admin`, `KC_BOOTSTRAP_ADMIN_PASSWORD=admin`
|
||||
- Gateway: Port 8081, Profil `dev` (per `SPRING_PROFILES_ACTIVE`)
|
||||
|
||||
## Troubleshooting (Top 5)
|
||||
- 401/403 am Gateway: Token fehlt/abgelaufen? Keycloak auf `http://localhost:8180` erreichbar?
|
||||
- 502/Bad Gateway: Zielservice down? Logs prüfen (`make services-logs`).
|
||||
- CORS im Browser: API über `api.meldestelle.*` bzw. `localhost:8081` aufrufen.
|
||||
- Consul leer: Services nicht registriert → Services neu starten.
|
||||
- Port-Konflikt: Belegte Ports mit `lsof -i :<port>` prüfen, Prozesse beenden.
|
||||
|
||||
## Diagramme (PlantUML)
|
||||
Siehe `docs/architecture/c4/` – Context & Container sowie Login‑Sequenz. In CI zu SVG rendern.
|
||||
@@ -0,0 +1,35 @@
|
||||
---
|
||||
owner: project-maintainers
|
||||
status: active
|
||||
review_cycle: 180d
|
||||
last_reviewed: 2025-10-15
|
||||
summary: Konsolidierte Übersicht aller relevanten lokalen Ports/URLs sowie der produktiven Domains (hinter Nginx).
|
||||
---
|
||||
|
||||
# Referenz: Ports & URLs
|
||||
|
||||
## Lokal (Standard-Setup)
|
||||
- Web App: http://localhost:4000
|
||||
- API Gateway: http://localhost:8081
|
||||
- Health: http://localhost:8081/actuator/health
|
||||
- Services (nur lokal):
|
||||
- Ping Service: http://localhost:8082
|
||||
- Members Service: http://localhost:8083
|
||||
- Horses Service: http://localhost:8084
|
||||
- Events Service: http://localhost:8085
|
||||
- Masterdata Service: http://localhost:8086
|
||||
- Keycloak (Auth): http://localhost:8180
|
||||
- Consul (Service Discovery): http://localhost:8500
|
||||
- Postgres: localhost:5432
|
||||
- Redis: localhost:6379
|
||||
- noVNC (Desktop): http://localhost:6080
|
||||
|
||||
Hinweis: In Produktion sind die einzelnen Services (8082–8086) nicht öffentlich erreichbar. Alle API-Aufrufe laufen über das Gateway.
|
||||
|
||||
## Produktion (hinter Nginx)
|
||||
- Web App: http://meldestelle.yourdomain.com
|
||||
- API Gateway: http://api.meldestelle.yourdomain.com
|
||||
- Health: http://api.meldestelle.yourdomain.com/actuator/health
|
||||
- VNC (optional): http://vnc.meldestelle.yourdomain.com
|
||||
|
||||
Optional HTTPS: gleiche Hosts mit https://, sobald Zertifikate aktiv sind.
|
||||
Reference in New Issue
Block a user