docs: translate remaining architectural guides to German and standardize formatting

Translated all remaining English architectural documents into German, including ADRs, guides, release notes, and reference materials. Standardized formatting across translated files, updated section headings, and localized inline comments within code examples for consistency.
This commit is contained in:
2026-03-06 14:02:51 +01:00
parent 4c0ff6008d
commit c086190097
8 changed files with 255 additions and 202 deletions
@@ -3,12 +3,12 @@ type: ADR
status: DRAFT
owner: Lead Architect
---
# PENDING DECISIONS: Backend Infrastructure & Architecture
# OFFENE ENTSCHEIDUNGEN: Backend-Infrastruktur & Architektur
**Status:** RESOLVED
**Date:** 2026-01-15
**See:** [ADR 001: Backend Infrastructure & Architecture Decisions](001-backend-infrastructure-decisions.md)
**Status:** GELÖST
**Datum:** 2026-01-15
**Siehe:** [ADR 001: Backend-Infrastruktur & Architekturentscheidungen](001-backend-infrastructure-decisions.md)
---
*This document is kept for historical context. All decisions have been moved to ADR 001.*
*Dieses Dokument wird aus historischen Gründen aufbewahrt. Alle Entscheidungen wurden in ADR 001 überführt.*
@@ -3,70 +3,70 @@ type: ADR
status: ACTIVE
owner: Lead Architect
---
# ADR 001: Backend Infrastructure & Architecture Decisions
# ADR 001: Backend-Infrastruktur & Architekturentscheidungen
**Status:** ACCEPTED
**Date:** 2026-01-15
**Author:** Lead Architect
**Context:** "Operation Tracer Bullet" (Phase 1) - Hardening of the `ping-service`.
**Status:** AKZEPTIERT
**Datum:** 2026-01-15
**Autor:** Lead Architect
**Kontext:** Operation Tracer Bullet" (Phase 1) Härtung des `ping-service`.
---
## 1. Persistence Strategy: JPA vs. Exposed
## 1. Persistenzstrategie: JPA vs. Exposed
**Decision:** **Hybrid Approach (Command/Query Separation)**
* **Primary (Command/Write):** We use **JPA (Hibernate)** for the standard "Write Model" in our microservices.
* *Reason:* Best integration with Spring Data, transaction management, and validation. Standard for Enterprise Spring Boot.
* **Secondary (Query/Read/Batch):** We allow **Exposed** for complex read queries or bulk operations where JPA overhead is too high.
* *Reason:* Kotlin-native, type-safe SQL generation, better performance for read-heavy operations.
**Entscheidung:** **Hybrider Ansatz (Command/Query-Trennung)**
* **Primär (Command/Write):** Wir verwenden **JPA (Hibernate)** für das Standard-„Write Model" in unseren Microservices.
* *Begründung:* Beste Integration mit Spring Data, Transaktionsverwaltung und Validierung. Standard für Enterprise Spring Boot.
* **Sekundär (Query/Read/Batch):** Wir erlauben **Exposed** für komplexe Leseabfragen oder Bulk-Operationen, bei denen der JPA-Overhead zu hoch ist.
* *Begründung:* Kotlin-nativ, typsichere SQL-Generierung, bessere Performance bei leselastigen Operationen.
**Action:**
* The `backend/infrastructure/persistence` module will support **both**.
* `ping-service` will primarily use **JPA** for its entities (`PingEntity`).
* We will NOT remove JPA from `ping-service`.
* We will NOT remove Exposed from `infrastructure/persistence`.
**Maßnahmen:**
* Das Modul `backend/infrastructure/persistence` unterstützt **beide** Ansätze.
* `ping-service` verwendet primär **JPA** für seine Entitäten (`PingEntity`).
* JPA wird NICHT aus dem `ping-service` entfernt.
* Exposed wird NICHT aus `infrastructure/persistence` entfernt.
## 2. Security Shared Module
## 2. Gemeinsames Security-Modul
**Decision:** **Extract `backend/infrastructure/security`**
* **Reason:** We strictly follow DRY (Don't Repeat Yourself). Security configuration (OAuth2 Resource Server, JWT Converter, CORS, Global Method Security) is identical for all microservices.
* **Scope:**
**Entscheidung:** **Extraktion von `backend/infrastructure/security`**
* **Begründung:** Wir folgen konsequent dem DRY-Prinzip (Don't Repeat Yourself). Die Sicherheitskonfiguration (OAuth2 Resource Server, JWT Converter, CORS, Global Method Security) ist für alle Microservices identisch.
* **Umfang:**
* `SecurityConfig`: Standard `SecurityFilterChain`.
* `KeycloakRoleConverter`: Extracting roles from JWT.
* `CorsConfig`: Centralized CORS policy.
* `KeycloakRoleConverter`: Rollen aus JWT extrahieren.
* `CorsConfig`: Zentrale CORS-Richtlinie.
**Action:**
* Create `backend/infrastructure/security`.
* Move security logic from `ping-service` (if any) to this module.
**Maßnahmen:**
* `backend/infrastructure/security` erstellen.
* Sicherheitslogik aus `ping-service` (falls vorhanden) in dieses Modul verschieben.
## 3. Messaging vs. Sync Protocol
## 3. Messaging vs. Sync-Protokoll
**Decision:** **REST-based Pull (Phase 1) -> Kafka (Phase 3)**
* **Phase 1 (Tracer Bullet):** We do **NOT** use Kafka for the simple `ping-service` yet.
* *Reason:* Keep the "Tracer Bullet" simple. We want to validate the HTTP/Auth chain first.
* **Phase 3 (Offline Sync):** We will introduce Kafka for the "Outbox Pattern" later.
* *Reason:* Reliable event delivery for offline clients requires a durable log.
**Entscheidung:** **REST-basiertes Pull (Phase 1) Kafka (Phase 3)**
* **Phase 1 (Tracer Bullet):** Für den einfachen `ping-service` wird Kafka noch NICHT verwendet.
* *Begründung:* Die „Tracer Bullet" soll einfach bleiben. Zuerst die HTTP/Auth-Kette validieren.
* **Phase 3 (Offline-Sync):** Kafka wird später für das „Outbox Pattern" eingeführt.
* *Begründung:* Zuverlässige Event-Zustellung für Offline-Clients erfordert ein dauerhaftes Log.
**Action:**
* Remove `reactor-kafka` dependency from `ping-service` for now to reduce noise.
* Focus on `PingEntity` (JPA) and REST endpoints.
**Maßnahmen:**
* `reactor-kafka`-Abhängigkeit vorerst aus `ping-service` entfernen, um die Komplexität zu reduzieren.
* Fokus auf `PingEntity` (JPA) und REST-Endpunkte.
## 4. Database Migration (Flyway)
## 4. Datenbank-Migration (Flyway)
**Decision:** **Database per Service (Option A)**
* **Reason:** Microservices autonomy. Each service owns its schema.
* **Location:** `src/main/resources/db/migration` inside each service module.
* **Naming:** `V{Version}__{Description}.sql` (e.g., `V1__init_ping_schema.sql`).
**Entscheidung:** **Datenbank pro Service (Option A)**
* **Begründung:** Autonomie der Microservices. Jeder Service besitzt sein eigenes Schema.
* **Ablageort:** `src/main/resources/db/migration` innerhalb jedes Service-Moduls.
* **Benennung:** `V{Version}__{Beschreibung}.sql` (z.B. `V1__init_ping_schema.sql`).
**Action:**
* `ping-service` must contain `V1__init.sql`.
**Maßnahmen:**
* `ping-service` muss `V1__init.sql` enthalten.
* `spring.flyway.enabled=true` in `application.yml`.
---
## Summary of Tasks for Senior Backend Developer
## Zusammenfassung der Aufgaben für den Senior Backend Developer
1. **Persistence:** Use JPA for `PingEntity`.
2. **Security:** Wait for `infrastructure/security` module (Architect will create skeleton) OR start implementing in `ping-service` and refactor later (preferred: Architect creates module now).
3. **Messaging:** Ignore Kafka for now.
4. **Flyway:** Create `V1__init.sql` in `ping-service`.
1. **Persistenz:** JPA für `PingEntity` verwenden.
2. **Security:** Auf das Modul `infrastructure/security` warten (Architect erstellt Skeleton) ODER direkt im `ping-service` implementieren und später refaktorieren (bevorzugt: Architect erstellt Modul sofort).
3. **Messaging:** Kafka vorerst ignorieren.
4. **Flyway:** `V1__init.sql` im `ping-service` erstellen.