*
ADR (Architecture Decision Record) — Kurzdokumentation einer architektonischen Entscheidung: welche Entscheidung getroffen wurde, warum, welche Alternativen geprüft wurden und wie bei geänderten Rahmenbedingungen vorzugehen ist.
*
DDD (Domain-Driven Design) — Entwurfsansatz, bei dem die Software um ein Modell der Fachdomäne herum strukturiert wird: zuerst werden Begriffe und Konzepte geklärt, anschließend wird der Code entwickelt und Systemgrenzen definiert.
*
Begrenzter Kontext (Bounded Context) — „Sinnbereich“ innerhalb eines Produkts, in dem Begriffe eindeutig definiert sind; Interaktionen mit anderen Kontexten erfolgen über klar definierte Schnittstellen und Verträge.
*
CI/CD (Continuous Integration / Continuous Delivery) — Automatisierte Erstellung, Tests und Bereitstellung von Änderungen; Ziel sind kleine, häufige und sichere Releases.
*
Trunk-Based Development — Arbeit mit kurzen Feature-Branches und schnellem Merge in den Haupt-Branch; reduziert Konflikte und beschleunigt die Auslieferung von Features.
*
SRE / SLI / SLO (Site Reliability Engineering / Service Level Indicator / Service Level Objective) — Ansatz zur Messung und Sicherstellung von Zuverlässigkeit; definiert, welche Service-Level den Nutzern zugesichert werden und wie deren Einhaltung überprüft wird.
*
DORA-Metriken — Kennzahlen zur Bewertung der Entwicklungsprozesse: Release-Frequenz, Lead Time, Change Failure Rate und Mean Time to Recovery.
*
Feature Flag / Canary / Blue-Green Deployment — Methoden zur schrittweisen Einführung neuer Funktionen und zur sicheren Rücknahme bei Problemen.
*
Circuit Breaker / Bulkhead — Architekturprinzipien zur Begrenzung der Ausbreitung von Fehlern: isolieren problematische Komponenten, sodass das Gesamtsystem stabil bleibt.
*
Observability — Konzept zur Systembeobachtbarkeit: Einsatz von Metriken, Logs und Traces, um Verhalten und Performance eines Systems unter Last zu verstehen.