feat: SOLID umbrella, German translations, catalog update

docs/anchors/bdd-given-when-then.de.adoc

@@ -0,0 +1,48 @@
+= BDD (Behavior-Driven Development)
+:categories: testing-quality
+:roles: software-developer, qa-engineer, business-analyst, product-owner
+:proponents: Dan North
+:related: tdd-london-school, tdd-chicago-school, user-story-mapping
+:tags: bdd, gherkin, cucumber, specification-by-example, three-amigos, given-when-then, living-documentation
+
+[%collapsible]
+====
+Auch bekannt als:: Specification by Example, Executable Specifications
+
+[discrete]
+== *Kernkonzepte*:
+
+Given-When-Then:: Strukturiertes Szenarioformat — Given eine Vorbedingung, When eine Aktion auftritt, Then ein erwartetes Ergebnis eintritt
+
+Specification by Example:: Konkrete Beispiele als ausführbare Spezifikationen, die das Systemverhalten definieren
+
+Three Amigos:: Kollaborative Entdeckungssitzungen zwischen Entwickler, Tester und Fachvertreter
+
+Gherkin-Syntax:: Domänenspezifische Sprache zum Schreiben menschenlesbarer, maschinenausführbarer Szenarien
+
+Living Documentation:: Tests, die als stets aktuelle Systemdokumentation dienen
+
+Outside-in-Spezifikation:: Vom gewünschten Geschäftsverhalten ausgehen, zur Implementierung hinarbeiten
+
+Ubiquitous Language:: Gemeinsames Vokabular, das technische und fachliche Stakeholder in Szenarien verbindet
+
+Discovery Workshops:: Strukturierte Gespräche, um Anforderungen durch Beispiele vor der Implementierung aufzudecken
+
+
+Schlüsselvertreter:: Dan North ("Introducing BDD", 2006), Entwickler von JBehave, das Cucumbers Design beeinflusste (Cucumber erstellt von Aslak Hellesøy, 2008)
+
+[discrete]
+== *Wann zu verwenden*:
+
+* Cross-funktionale Teams, die ein gemeinsames Verständnis der Anforderungen benötigen
+* Systeme, in denen Geschäftsregeln komplex sind und klare Dokumentation erfordern
+* Projekte, die ausführbare Akzeptanzkriterien benötigen
+* Überbrückung von Kommunikationslücken zwischen technischen und nicht-technischen Stakeholdern
+
+[discrete]
+== *Verwandte Anker*:
+
+* <<tdd-london-school,TDD, London School>> - Outside-in-Entwicklungsansatz, der BDD ergänzt
+* <<tdd-chicago-school,TDD, Chicago School>> - Entwicklerfokussierte TDD-Praxis
+* <<user-story-mapping,User Story Mapping>> - Anforderungsermittlung, die BDD-Szenarien speist
+====

docs/anchors/cqrs.de.adoc

@@ -0,0 +1,49 @@
+= CQRS (Command Query Responsibility Segregation)
+:categories: software-architecture
+:roles: software-architect, software-developer
+:proponents: Greg Young, Bertrand Meyer, Udi Dahan
+:related: domain-driven-design, hexagonal-architecture, fowler-patterns
+:tags: cqrs, cqs, architecture, commands, queries, read-write-separation
+
+[%collapsible]
+====
+Auch bekannt als:: CQS auf Architekturebene
+
+[discrete]
+== *Kernkonzepte*:
+
+Command Query Separation (CQS):: Bertrand Meyers Prinzip — Methoden ändern entweder den Zustand (Commands) oder geben Daten zurück (Queries), niemals beides
+
+Commands:: Schreiboperationen, die den Zustand ändern und void zurückgeben; repräsentieren Absichten als unveränderliche Command-Objekte
+
+Queries:: Leseoperationen, die Daten ohne Seiteneffekte zurückgeben; sicher wiederholbar und cachebar
+
+Getrennte Lese-/Schreibmodelle:: Unabhängige Datenmodelle, die für ihren jeweiligen Zweck optimiert sind
+
+Eventual Consistency:: Das Lesemodell kann hinter dem Schreibmodell zurückbleiben; akzeptabler Kompromiss für Skalierbarkeit
+
+Ereignisbasierte Synchronisation:: Domain Events propagieren Änderungen von der Schreibseite zu Lesemodell-Projektionen
+
+Unabhängige Skalierbarkeit:: Lese- und Schreibseite können unabhängig skaliert, deployt und optimiert werden
+
+Event Sourcing optional:: CQRS erfordert kein Event Sourcing; die Muster sind komplementär, aber unabhängig
+
+
+Schlüsselvertreter:: Greg Young (prägte CQRS), Bertrand Meyer (CQS-Ursprung, "Object-Oriented Software Construction", 1988), Udi Dahan
+
+[discrete]
+== *Wann zu verwenden*:
+
+* Systeme mit asymmetrischer Lese-/Schreiblast
+* Komplexe Domänen, in denen Lese- und Schreibmodelle erheblich voneinander abweichen
+* Event-Sourced-Systeme, die materialisierte Views erfordern
+* Hochperformante Systeme, die unabhängige Skalierung von Lese- und Schreibzugriffen benötigen
+* Kollaborative Domänen mit aufgabenbasierten UIs
+
+[discrete]
+== *Verwandte Anker*:
+
+* <<domain-driven-design,Domain-Driven Design>> - Wird oft mit CQRS für komplexe Domänen kombiniert
+* <<hexagonal-architecture,Hexagonal Architecture>> - Ports und Adapter ergänzen die CQRS-Trennung
+* <<fowler-patterns,Fowler Patterns>> - CQRS baut auf Enterprise-Application-Patterns auf
+====

docs/anchors/event-driven-architecture.de.adoc

@@ -0,0 +1,50 @@
+= Event-Driven Architecture
+:categories: software-architecture
+:roles: software-architect, software-developer, devops-engineer
+:proponents: Gregor Hohpe, Bobby Woolf, Martin Fowler
+:related: domain-driven-design, hexagonal-architecture, clean-architecture
+:tags: eda, events, async, messaging, publish-subscribe, decoupling, eventual-consistency
+
+[%collapsible]
+====
+Auch bekannt als:: EDA, Message-Driven Architecture
+
+[discrete]
+== *Kernkonzepte*:
+
+Event Producers und Consumers:: Komponenten kommunizieren durch das Aussenden und Reagieren auf Events statt durch direkte Aufrufe
+
+Publish-Subscribe:: Produzenten veröffentlichen Events, ohne zu wissen, welche Konsumenten sie verarbeiten werden
+
+Asynchrone Entkopplung:: Sender und Empfänger arbeiten zeitlich unabhängig; kein blockierendes Request-Response
+
+Message Queue:: Vermittler, der Events zwischen Produzenten und Konsumenten puffert (SQS, RabbitMQ, Kafka)
+
+At-least-once Delivery:: Die meisten Messaging-Systeme garantieren Zustellung, können aber Duplikate liefern, was idempotente Konsumenten erfordert
+
+Eventual Consistency:: Der Systemzustand konvergiert über die Zeit, anstatt nach jeder Operation sofort konsistent zu sein
+
+Event Notification:: Leichtgewichtiges Event-Signal, dass etwas passiert ist; Konsumenten entscheiden, ob sie handeln
+
+Event-Carried State Transfer:: Events tragen genug Daten, damit Konsumenten verarbeiten können, ohne den Produzenten zurückzurufen
+
+Choreographie vs. Orchestrierung:: Events können verteilte Workflows implizit (Choreographie) oder über einen zentralen Koordinator (Orchestrierung) auslösen
+
+
+Schlüsselvertreter:: Gregor Hohpe, Bobby Woolf ("Enterprise Integration Patterns", 2003), Martin Fowler ("What do you mean by Event-Driven?", 2017)
+
+[discrete]
+== *Wann zu verwenden*:
+
+* Systeme, die lose Kopplung zwischen Komponenten erfordern
+* Workloads mit asynchronen Verarbeitungspipelines
+* Architekturen, die unabhängige Skalierung von Produzenten und Konsumenten benötigen
+* Verteilte Systeme, in denen Komponenten sich unabhängig weiterentwickeln müssen
+
+[discrete]
+== *Verwandte Anker*:
+
+* <<domain-driven-design,Domain-Driven Design>> - Domain Events sind ein DDD-Baustein
+* <<hexagonal-architecture,Hexagonal Architecture>> - Message Queues als Driven Adapters
+* <<clean-architecture,Clean Architecture>> - Events überqueren Architekturgrenzen über Interfaces
+====

docs/anchors/gof-abstract-factory-pattern.de.adoc

@@ -0,0 +1,32 @@
+= GoF-Abstract Factory Pattern
+:categories: design-principles
+:roles: software-developer, software-architect
+:umbrella: gof-design-patterns
+:tier: 2
+:proponents: Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides
+:tags: GoF, design pattern, creational, abstract factory, family, platform independence
+
+[%collapsible]
+====
+Vollständiger Name:: GoF Abstract Factory Pattern (Creational)
+
+Auch bekannt als:: Kit
+
+[discrete]
+== *Absicht*:
+Biete ein Interface zur Erzeugung von Familien verwandter oder abhängiger Objekte, ohne deren konkrete Klassen zu spezifizieren.
+
+[discrete]
+== *Wann zu verwenden*:
+* Wenn ein System unabhängig davon sein soll, wie seine Produkte erzeugt werden
+* Wenn ein System mit einer von mehreren Produktfamilien konfiguriert werden soll
+* Wenn verwandte Produktobjekte für die gemeinsame Verwendung entworfen sind und du diese Einschränkung durchsetzen musst
+
+[discrete]
+== *Prompt-Beispiel*:
+"Erstelle eine Abstract Factory nach GoF, die UI-Komponenten für verschiedene Plattformen (Web, Mobile, Desktop) erzeugt, ohne dass der Client die konkreten Klassen kennen muss."
+
+[discrete]
+== *Verwandte Anker*:
+* <<gof-design-patterns,GoF Design Patterns>> (Umbrella)
+====

docs/anchors/gof-adapter-pattern.de.adoc

@@ -0,0 +1,31 @@
+= GoF-Adapter Pattern
+:categories: design-principles
+:roles: software-developer, software-architect
+:umbrella: gof-design-patterns
+:tier: 1
+:proponents: Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides
+:tags: GoF, design pattern, structural, adapter, wrapper, interface conversion, compatibility
+
+[%collapsible]
+====
+Vollständiger Name:: GoF Adapter Pattern (Structural)
+
+Auch bekannt als:: Wrapper
+
+[discrete]
+== *Absicht*:
+Konvertiere das Interface einer Klasse in ein anderes Interface, das Clients erwarten.
+
+[discrete]
+== *Wann zu verwenden*:
+* Wenn du eine existierende Klasse verwenden möchtest, deren Interface nicht zu deinen Anforderungen passt
+* Wenn du eine wiederverwendbare Klasse erstellen möchtest, die mit nicht verwandten Klassen zusammenarbeitet
+
+[discrete]
+== *Prompt-Beispiel*:
+"Erstelle einen Adapter nach GoF, der die Legacy-API auf unser neues Interface mappt, ohne den bestehenden Code zu ändern."
+
+[discrete]
+== *Verwandte Anker*:
+* <<gof-design-patterns,GoF Design Patterns>> (Umbrella)
+====

docs/anchors/gof-bridge-pattern.de.adoc

@@ -0,0 +1,30 @@
+= GoF-Bridge Pattern
+:categories: design-principles
+:roles: software-developer, software-architect
+:umbrella: gof-design-patterns
+:tier: 2
+:proponents: Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides
+:tags: GoF, design pattern, structural, bridge, abstraction, implementation, decoupling
+
+[%collapsible]
+====
+Vollständiger Name:: GoF Bridge Pattern (Structural)
+
+[discrete]
+== *Absicht*:
+Entkopple eine Abstraktion von ihrer Implementierung, sodass beide unabhängig voneinander variieren können.
+
+[discrete]
+== *Wann zu verwenden*:
+* Wenn du eine permanente Bindung zwischen einer Abstraktion und ihrer Implementierung vermeiden möchtest
+* Wenn sowohl die Abstraktionen als auch ihre Implementierungen durch Unterklassenbildung erweiterbar sein sollen
+* Wenn Änderungen in der Implementierung keine Auswirkungen auf Clients haben sollen
+
+[discrete]
+== *Prompt-Beispiel*:
+"Trenne die Rendering-Abstraktion von der plattformspezifischen Implementierung nach dem GoF-Bridge Pattern, damit beide unabhängig erweitert werden können."
+
+[discrete]
+== *Verwandte Anker*:
+* <<gof-design-patterns,GoF Design Patterns>> (Umbrella)
+====

docs/anchors/gof-builder-pattern.de.adoc

@@ -0,0 +1,29 @@
+= GoF-Builder Pattern
+:categories: design-principles
+:roles: software-developer, software-architect
+:umbrella: gof-design-patterns
+:tier: 1
+:proponents: Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides
+:tags: GoF, design pattern, creational, builder, construction, fluent interface, complex objects
+
+[%collapsible]
+====
+Vollständiger Name:: GoF Builder Pattern (Creational)
+
+[discrete]
+== *Absicht*:
+Trenne die Konstruktion eines komplexen Objekts von seiner Repräsentation, sodass derselbe Konstruktionsprozess verschiedene Repräsentationen erzeugen kann.
+
+[discrete]
+== *Wann zu verwenden*:
+* Wenn der Algorithmus zur Erzeugung eines komplexen Objekts unabhängig von den Teilen und ihrer Zusammensetzung sein soll
+* Wenn der Konstruktionsprozess verschiedene Repräsentationen ermöglichen muss
+
+[discrete]
+== *Prompt-Beispiel*:
+"Implementiere einen Builder nach GoF für das QueryObject, mit Fluent API für Filter, Sortierung und Pagination."
+
+[discrete]
+== *Verwandte Anker*:
+* <<gof-design-patterns,GoF Design Patterns>> (Umbrella)
+====

docs/anchors/gof-chain-of-responsibility-pattern.de.adoc

@@ -0,0 +1,30 @@
+= GoF-Chain of Responsibility Pattern
+:categories: design-principles
+:roles: software-developer, software-architect
+:umbrella: gof-design-patterns
+:tier: 2
+:proponents: Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides
+:tags: GoF, design pattern, behavioral, chain of responsibility, handler, pipeline, middleware
+
+[%collapsible]
+====
+Vollständiger Name:: GoF Chain of Responsibility Pattern (Behavioral)
+
+[discrete]
+== *Absicht*:
+Vermeide die Kopplung des Senders einer Anfrage an seinen Empfänger, indem mehr als ein Objekt die Möglichkeit erhält, die Anfrage zu bearbeiten. Verkette die empfangenden Objekte und leite die Anfrage entlang der Kette weiter.
+
+[discrete]
+== *Wann zu verwenden*:
+* Wenn mehr als ein Objekt eine Anfrage bearbeiten kann und der Handler nicht im Voraus bekannt ist
+* Wenn du eine Anfrage an eines von mehreren Objekten senden möchtest, ohne den Empfänger explizit anzugeben
+* Wenn die Menge der Objekte, die eine Anfrage bearbeiten können, dynamisch festgelegt werden soll
+
+[discrete]
+== *Prompt-Beispiel*:
+"Implementiere eine Middleware-Pipeline nach dem GoF-Chain of Responsibility Pattern, bei der jeder Handler die Anfrage entweder verarbeitet oder an den nächsten weitergibt."
+
+[discrete]
+== *Verwandte Anker*:
+* <<gof-design-patterns,GoF Design Patterns>> (Umbrella)
+====

docs/anchors/gof-command-pattern.de.adoc

@@ -0,0 +1,30 @@
+= GoF-Command Pattern
+:categories: design-principles
+:roles: software-developer, software-architect
+:umbrella: gof-design-patterns
+:tier: 1
+:proponents: Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides
+:tags: GoF, design pattern, behavioral, command, undo, queue, encapsulation, action
+
+[%collapsible]
+====
+Vollständiger Name:: GoF Command Pattern (Behavioral)
+
+[discrete]
+== *Absicht*:
+Kapsle eine Anfrage als Objekt, sodass du Clients mit verschiedenen Anfragen parametrisieren, Anfragen in Warteschlangen stellen oder protokollieren und rückgängig machbare Operationen unterstützen kannst.
+
+[discrete]
+== *Wann zu verwenden*:
+* Wenn du Objekte mit einer auszuführenden Aktion parametrisieren möchtest
+* Wenn du Undo/Redo-Funktionalität benötigst
+* Wenn du Anfragen in Warteschlangen stellen, protokollieren oder zeitlich planen musst
+
+[discrete]
+== *Prompt-Beispiel*:
+"Implementiere ein Undo/Redo-System nach dem GoF-Command Pattern, bei dem jede Benutzeraktion als Command-Objekt gekapselt wird."
+
+[discrete]
+== *Verwandte Anker*:
+* <<gof-design-patterns,GoF Design Patterns>> (Umbrella)
+====

docs/anchors/gof-composite-pattern.de.adoc

@@ -0,0 +1,29 @@
+= GoF-Composite Pattern
+:categories: design-principles
+:roles: software-developer, software-architect
+:umbrella: gof-design-patterns
+:tier: 2
+:proponents: Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides
+:tags: GoF, design pattern, structural, composite, tree, hierarchy, part-whole
+
+[%collapsible]
+====
+Vollständiger Name:: GoF Composite Pattern (Structural)
+
+[discrete]
+== *Absicht*:
+Setze Objekte zu Baumstrukturen zusammen, um Teil-Ganzes-Hierarchien darzustellen. Composite ermöglicht es Clients, einzelne Objekte und Kompositionen einheitlich zu behandeln.
+
+[discrete]
+== *Wann zu verwenden*:
+* Wenn du Teil-Ganzes-Hierarchien von Objekten darstellen möchtest
+* Wenn Clients den Unterschied zwischen Kompositionen von Objekten und einzelnen Objekten ignorieren können sollen
+
+[discrete]
+== *Prompt-Beispiel*:
+"Modelliere das Dateisystem nach dem GoF-Composite Pattern, sodass Dateien und Ordner einheitlich behandelt werden können."
+
+[discrete]
+== *Verwandte Anker*:
+* <<gof-design-patterns,GoF Design Patterns>> (Umbrella)
+====

docs/anchors/gof-decorator-pattern.de.adoc

@@ -0,0 +1,31 @@
+= GoF-Decorator Pattern
+:categories: design-principles
+:roles: software-developer, software-architect
+:umbrella: gof-design-patterns
+:tier: 1
+:proponents: Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides
+:tags: GoF, design pattern, structural, decorator, wrapper, dynamic behavior, composition
+
+[%collapsible]
+====
+Vollständiger Name:: GoF Decorator Pattern (Structural)
+
+Auch bekannt als:: Wrapper
+
+[discrete]
+== *Absicht*:
+Füge einem Objekt dynamisch zusätzliche Verantwortlichkeiten hinzu. Decorators bieten eine flexible Alternative zur Unterklassenbildung.
+
+[discrete]
+== *Wann zu verwenden*:
+* Um Objekten dynamisch und transparent Verantwortlichkeiten hinzuzufügen
+* Wenn Erweiterung durch Unterklassenbildung unpraktisch ist
+
+[discrete]
+== *Prompt-Beispiel*:
+"Verwende das GoF-Decorator Pattern, um dem Logger dynamisch Formatierung, Timestamp und Filterung hinzuzufügen."
+
+[discrete]
+== *Verwandte Anker*:
+* <<gof-design-patterns,GoF Design Patterns>> (Umbrella)
+====