Ergänzungen Phase 2
| Muster | Stelle | Warum |
|---|---|---|
| Publisher Port | OrderEventPublisher | Anwendung bleibt unabhängig vom Broker |
| Messaging Adapter | RabbitOrderEventPublisher | RabbitMQ wird am Rand gekapselt |
| Polling Publisher | JdbcOutboxRelayRepository + OutboxRelayJob | Outbox Events zuverlässig veröffentlichen |
| Event Consumer | BillingOrderAcceptedConsumer | lose Kopplung zwischen Order und Billing |
| Dead Letter Queue | RabbitMQ Definitions | Fehlerhafte Nachrichten isolieren |
Ergänzungen Phase 3
| Muster | Stelle | Warum |
|---|---|---|
| Security Boundary | SecurityConfiguration | zentrale Schutzschicht am Runtime-Rand |
| Anti-Corruption Layer | RealmRoleJwtAuthenticationConverter | Keycloak Claims werden in Spring Authorities übersetzt |
| Method-Level Authorization | BillingController | fachliche Operationen rollenbasiert absichern |
| Policy Mapping | Security-Regeln | Endpunkte werden explizit Rollen zugeordnet |
Ergänzungen Phase 4
| Muster | Stelle | Warum |
|---|---|---|
| Test Fixture | RealSystemTestEnvironment | reproduzierbare Test-Infrastruktur |
| Test Helper | DatabaseAssertions | lesbare technische Prüfungen |
| End-to-End Test | OrderAcceptanceE2EIT | gesamter Systemfluss dokumentiert |
| Security Scenario Test | SecurityE2EIT | Rollenpfade nachvollziehbar machen |
| Contract Test Vorbereitung | WireMock Mappings | externe Provider stabil simulieren |
Ergänzungen Phase 5
| Muster | Stelle | Warum |
|---|---|---|
| Observability Facade | BusinessMetrics | Fachmetriken zentral kapseln |
| Health Check | OutboxHealthIndicator | Betriebsrisiken sichtbar machen |
| Metrics Binder | OutboxMetricsBinder | technische Zustände als Metriken veröffentlichen |
| Correlation ID | RequestCorrelationFilter | Requests und Logs verbinden |
| Dashboard as Code | Grafana Provisioning | Dashboards versionieren |
| Alert as Code | Prometheus Rules | Betriebsregeln versionieren |
Ergänzungen Phase 6
| Muster | Stelle | Warum |
|---|---|---|
| Resilience Decorator | ResilientPaymentGateway | schützt externen Gateway ohne Fachlogik zu verändern |
| Circuit Breaker | Payment Provider | Fehlerkaskaden stoppen |
| Retry | Payment Provider | transiente Fehler ausgleichen |
| Timeout / TimeLimiter | Payment Provider | maximale Wartezeit begrenzen |
| Bulkhead | Payment Provider | parallele Providerlast begrenzen |
| Rate Limiter | RateLimitingFilter | API vor Request-Flut schützen |
| Error Boundary | ResilienceAdvice | stabile API-Fehler statt technische Details |
Ergänzungen Phase 7
| Muster | Stelle | Warum |
|---|---|---|
| Pipeline as Code | .github/workflows/ci.yml | Build und Gates versioniert beschreiben |
| Quality Gate | scripts/quality/run-quality-gates.sh | Lieferfähigkeit prüfbar machen |
| Release Candidate | CI Artefakte | geprüfte Zwischenstände erzeugen |
| Compliance by Design | SBOM und Lizenzbericht | Compliance nicht erst am Ende behandeln |
Ergänzungen Phase 8
| Muster | Stelle | Warum |
|---|---|---|
| Deployment Boundary | Kubernetes/Helm Artefakte | Runtime von Umgebung trennen |
| Configuration Externalization | ConfigMap/Secret/values.yaml | Konfiguration nicht im Code hart verdrahten |
| Environment Overlay | Kustomize Overlays | lokale, OpenShift- und Prod-Unterschiede sauber trennen |
| Release Template | Helm Chart | parametrische Releases ermöglichen |
| Health Probe Pattern | Liveness/Readiness | Betriebsfähigkeit messbar machen |
Ergänzungen Phase 9
| Muster | Stelle | Warum |
|---|---|---|
| Expand/Contract | migration-rollback-strategy.md | sichere Schemaänderungen in mehreren Releases |
| Forward-Fix | Migrationsstrategie | produktionsnaher Umgang mit fehlerhaften Migrationen |
| Operational Runbook | docs/runbooks/database-* | wiederholbare Betriebsabläufe |
| Retention Pattern | outbox-retention.sql | operative Tabellen kontrolliert klein halten |
| Seed Data Separation | database/seed | Demo/Testdaten getrennt von Produktionsmigrationen |
Ergänzungen Phase 10
| Muster / Prinzip | Stelle | Warum |
|---|---|---|
| Operational Readiness | docs/operations | Betrieb wird Teil der Architektur |
| Incident Command | incident-response.md | strukturierte Störungsbearbeitung |
| Recovery Plan | disaster-recovery.md | Wiederherstellung nachvollziehbar machen |
| Service Level Model | sla-slo-model.md | technische Signale in Betriebsziele übersetzen |