docs: refine architecture patterns with Light-CQRS and Write Manager details

architektur-patterns.md

@@ -2,7 +2,7 @@
 
 ## 1. UseCase Pattern (`src/Logic`)
 
-Das UseCase Pattern bildet das Herzstück der Business-Logik. Jeder Anwendungsfall wird als eigenständige Klasse implementiert, um eine klare Trennung der Verantwortlichkeiten und eine hohe Testbarkeit zu gewährleisten.
+Das UseCase Pattern bildet das Herzstück der Business-Logik. Zusammen mit dem Read Pattern (Sektion 2) folgt die Architektur einem **Light-CQRS Ansatz** (Command Query Responsibility Segregation), bei dem Schreiboperationen (Commands/UseCases) strikt von Leseoperationen (Queries) getrennt werden, um Komplexität zu reduzieren und die Performance zu optimieren. Jeder Anwendungsfall wird als eigenständige Klasse implementiert, um eine klare Trennung der Verantwortlichkeiten und eine hohe Testbarkeit zu gewährleisten.
 
 ### Struktur & Definition
 - **Interface**: Alle UseCases müssen das `UseCaseInterface` implementieren.
@@ -183,14 +183,58 @@ readonly class OrderProvider
 
 ## 3. Write Pattern (`src/Logic` $\rightarrow$ `src/Data`)
 
-Das Write Pattern beschreibt den Weg einer Datenänderung. Es stellt sicher, dass Geschäftsregeln validiert werden, bevor Daten persistiert werden.
+Das Write Pattern definiert den Weg von einer Zustandsänderung hin zur Persistenz. Es stellt sicher, dass Schreiboperationen atomar erfolgen und die Integrität der Business-Models gewahrt bleibt.
 
-*(Inhalt hier gekürzt - bitte basierend auf existierender Implementierung ergänzen)*
+### Der Datenfluss
+`UI Layer` $\rightarrow$ **UseCase** $\rightarrow$ **Manager** (optional) $\rightarrow$ **Processor**
+
+#### Manager (Logic Layer - optional)
+- **Zweck**: Koordinationsschicht für Schreiboperationen.
+- **Verantwortung**: Primär zuständig für die Orchestrierung von Nebenwirkungen, die außerhalb der Kern-Transaktion liegen oder die Datenkonsistenz über verschiedene Ebenen hinweg sicherstellen müssen (z. B. Triggerung der **Cache-Invalidierung** in der Read-Layer nach erfolgreichem Write).
+- **Schnittstelle**: Besitzt wie im Read Pattern ein eigenes Interface zur Gewährleistung von Testbarkeit.
+
+#### Processor (Data Layer)
+- **Zweck**: Übernimmt die physische Persistierung eines Business-Models.
+- **Schnittstelle**: Das `ProcessorInterface` liegt zwingend in der **Logic Layer** (Dependency Inversion).
+- **Input**: Ein Business-Model.
+- **Rückgabewert**: Das aktualisierte/neu erstellte Business-Model (z.B. zur Rückgabe von generierten IDs).
+- **Fehlerbehandlung**: Wirft im Fehlerfall direkt **Domain-Exceptions**.
+- **Strategie**: Verfolgt den "All or Nothing" Ansatz; die übergeordnete Transaktion wird vom UseCase gesteuert.
+- **Granularität**: Fokus auf eine einzelne Entität pro Processor.
+
+### Code Beispiel
+
+#### Processor Interface & Implementierung
 ```php
+namespace App\Logic\Sales\Order;
+
+use App\Logic\Sales\Order\Model\Order;
+
+interface OrderProcessorInterface
+{
+    public function save(Order $order): Order;
+    public function delete(string $id): void;
+}
+
+// --- Data Layer ---
+namespace App\Data\Sales\Order\Processor;
+
+use App\Logic\Sales\Order\OrderProcessorInterface;
+use App\Logic\Sales\Order\Model\Order;
+
+readonly class OrderProcessor implements OrderProcessorInterface
+{
+    public function save(Order $order): Order
+    {
+        // Persistenz-Logik (DB/API) ...
+        return $order; // Hier ggf. mit generierter ID zurückgeben
+    }
+
     public function delete(string $id): void
     {
         // Lösch-Logik ...
     }
+}
 ```
 
 ## 4. Transaction Management (`src/Logic` $\rightarrow$ `src/Data`)