Glossar
Fach- und Technikbegriffe, wie sie in diesem Projekt verwendet werden - mit englischem Originalbegriff, falls in der Praxis meist Englisch verwendet wird. Wird über alle Phasen hinweg ergänzt (jede neue Phase, jedes neue Pattern bringt neue Begriffe mit).
Domain-Driven Design (DDD)
| Begriff (EN) | Erklärung |
|---|---|
| Bounded Context | Abgegrenzter fachlicher Geltungsbereich eines Modells mit eigener, konsistenter Sprache (Ubiquitous Language). In diesem Projekt: ein Bounded Context = ein Microservice. |
| Ubiquitous Language | Gemeinsame, präzise Fachsprache zwischen Entwickler:innen und Fachexpert:innen - im Code widergespiegelt (Klassennamen wie Loan, nicht Transaction). |
| Aggregate / Aggregate Root | Konsistenzgrenze; nur das Root ist von außen erreichbar. Siehe domain-model.md. |
| Value Object | Unveränderliches, wertbasiertes Objekt ohne Identität (Isbn, Money). |
| Entity | Objekt mit fachlicher Identität über die Zeit. |
| Domain Event | Fachlich bedeutsames, unveränderliches Ereignis der Vergangenheit. |
| Rich Domain Model | Geschäftsregeln leben in den Entities/Aggregates selbst (Gegenteil: Anemic Domain Model). |
| Core / Supporting / Generic Subdomain | Klassifikation nach Wichtigkeit für den Wettbewerbsvorteil (Eric Evans, "Domain-Driven Design"). |
| Context Map | Diagramm/Beschreibung, wie Bounded Contexts fachlich zueinander in Beziehung stehen (z. B. "Customer/Supplier", "Published Language"). |
Messaging / Event-Driven Architecture
| Begriff (EN) | Erklärung |
|---|---|
| Event | "Etwas ist passiert" - 1:N, mehrere unabhängige Konsumenten möglich. Siehe ADR-0003. |
| Command | "Tu dies" - 1:1, genau ein Bearbeiter. Siehe ADR-0003. |
| Event Sourcing | (In diesem Projekt NICHT verwendet, nur erwähnt zur Abgrenzung) Zustand wird ausschließlich aus der Folge aller Events rekonstruiert, statt als aktueller Snapshot in einer Tabelle gespeichert zu werden. |
| Transactional Outbox | Pattern, um "DB-Schreiben" und "Event veröffentlichen" atomar zu machen, ohne verteilte Transaktion: das Event landet in derselben DB-Transaktion in einer Outbox-Tabelle und wird asynchron nachveröffentlicht. Siehe lending-service (Phase 3). |
| Idempotent Consumer | Ein Konsument, der dieselbe Nachricht mehrfach verarbeiten kann, ohne einen falschen Endzustand zu erzeugen (wichtig bei "at-least-once"-Zustellung). |
| Dead Letter Queue (DLQ) | Warteschlange für Nachrichten, die nach mehreren Zustellversuchen nicht erfolgreich verarbeitet werden konnten. |
| Consumer Group (Kafka) | Menge kooperierender Konsumenten, die sich die Partitionen eines Topics aufteilen. |
| Partition (Kafka) | Unterteilung eines Topics; garantiert Reihenfolge NUR innerhalb einer Partition. |
| Exchange / Queue / Routing Key (RabbitMQ, AMQP) | Exchange verteilt Nachrichten anhand eines Routing Keys an eine oder mehrere gebundene Queues. |
| Saga | Ablauf, der mehrere lokale Transaktionen über verschiedene Services hinweg koordiniert, mit kompensierenden Aktionen statt einer verteilten Transaktion. |
| Choreography vs. Orchestration (Saga-Varianten) | Choreography: Services reagieren dezentral aufeinander per Events. Orchestration: eine zentrale Komponente steuert den Ablauf aktiv (hier: lending-service). |
Security / OAuth2 / OIDC
| Begriff (EN) | Erklärung |
|---|---|
| OAuth2 | Autorisierungs-Framework: "wer darf was" via Access Tokens, ohne dass der Client das Passwort kennt. |
| OpenID Connect (OIDC) | Authentifizierungsschicht auf OAuth2: liefert zusätzlich ein ID-Token mit Nutzeridentität. |
| JWT (JSON Web Token) | Signiertes, selbstbeschreibendes Token-Format - der Server kann es ohne Datenbankabfrage validieren (nur die Signatur prüfen). |
| Authorization Code Flow + PKCE | Der empfohlene OAuth2-Login-Ablauf für Single-Page-Apps/mobile Apps ohne Client-Secret; PKCE verhindert Code-Interception-Angriffe. |
| Resource Server | Ein Service, der eingehende Access Tokens validiert und darauf basierend Zugriff gewährt (jeder Fachservice hier). |
| Token Relay | Das Gateway reicht das vom Client mitgeschickte Access Token unverändert an die Backend-Services weiter. |
| Realm (Keycloak-Begriff) | Isolierter Mandant in Keycloak mit eigenen Nutzern, Rollen, Clients. |
| Claim | Einzelne Information innerhalb eines JWT (z. B. sub, realm_access.roles). |
Resilience / verteilte Systeme
| Begriff (EN) | Erklärung |
|---|---|
| Circuit Breaker | Unterbricht nach wiederholten Fehlern automatisch weitere Aufrufe an einen instabilen Dienst, statt ihn mit Anfragen zu überhäufen. |
| Retry | Automatische Wiederholung fehlgeschlagener Aufrufe (meist mit Backoff-Strategie). |
| Bulkhead | Begrenzung gleichzeitiger Aufrufe an eine Ressource, damit ein überlasteter Abhängigkeitsdienst nicht das gesamte System lahmlegt. |
| Rate Limiting | Begrenzung der Anfragen pro Zeiteinheit (z. B. am API-Gateway). |
| Timeout | Maximale Wartezeit auf eine Antwort, bevor der Aufruf als fehlgeschlagen gilt. |
| Backpressure | Mechanismus, mit dem ein langsamer Konsument einem schnellen Produzenten signalisiert, langsamer zu senden (relevant in reaktiven Systemen wie dem API-Gateway). |
Testing
| Begriff (EN) | Erklärung |
|---|---|
| Test Pyramid | Faustregel für das Mengenverhältnis: viele schnelle Unit-Tests, weniger Integrationstests, wenige End-to-End-Tests. |
| Testcontainers | Bibliothek, die echte Infrastruktur (Postgres, Kafka, ...) in Containern für Tests hochfährt statt sie zu mocken. Spricht einen Docker-kompatiblen Socket - hier den von Podman. |
| Fitness Function | Automatisierter Test, der eine Architekturregel prüft (hier: ArchUnit-Tests in architecture-tests). |
| Test Data Builder / Object Mother | Pattern zum lesbaren Aufbau von Testdaten (statt langer Konstruktoraufrufe). |
| Contract Testing | Prüft, ob Producer und Consumer einer API/eines Events kompatibel bleiben, ohne beide gemeinsam laufen lassen zu müssen. |
DevOps
| Begriff (EN) | Erklärung |
|---|---|
| Reactor (Maven) | Die Menge aller Module eines Multi-Module-Builds inkl. ihrer Abhängigkeitsreihenfolge. |
| Podman | Container-Engine (Red Hat, Apache 2.0), die dieses Projekt statt Docker nutzt: rootless und daemonless, mit Docker-kompatibler CLI und API. podman compose/podman build lesen die vorhandenen docker-compose.yml/Dockerfile-Dateien unverändert. |
| Podman Machine | Unter Windows/macOS die Linux-VM (WSL2 bzw. Apple-VM), in der Podmans Container tatsächlich laufen - via podman machine init / podman machine start. Auf Linux nicht nötig. |
| Buildah | Das Werkzeug hinter podman build - baut OCI-Images aus einem Dockerfile/Containerfile, auch vollständig rootless und ohne Daemon. |
| BOM (Bill of Materials) | Eine pom.xml mit <dependencyManagement>, die konsistente Versionen für eine ganze Bibliotheksfamilie vorgibt (z. B. spring-boot-dependencies). |
| Helm Chart | Paket-Format für Kubernetes-Ressourcen mit Templating (values.yaml parametrisiert Manifeste). |
| HPA (Horizontal Pod Autoscaler) | Kubernetes-Ressource, die die Anzahl laufender Pods automatisch an die Last anpasst. |
| GitOps | Betriebsmodell, bei dem der gewünschte Systemzustand deklarativ in Git liegt und automatisch abgeglichen wird. |