diff --git a/architektur.md b/architektur.md
index 2f7074e..5b9c801 100644
--- a/architektur.md
+++ b/architektur.md
@@ -6,10 +6,10 @@ Dieses Dokument beschreibt die technische Architektur des Projekts. Es dient als
 
 Die Anwendung ist in drei strikt getrennte Layer unterteilt:
 
-### UI layer (`src/UI`)
+### UI Layer (`src/UI`)
 - **Verantwortung**: Präsentation, Handling von User-Input, API-Endpunkte, CLI-Commands.
 - **Struktur**: Folgt einer domänenorientierten Struktur `src/UI/{Module}/{Interface}/{Feature}/...` (z.B. `src/UI/Sales/Http/OrderController.php`), um maximale Symmetrie zu den anderen Layern zu gewährleisten.
-- **Regel**: Darf ausschließlich die Logic-Layer aufrufen. Ein direkter Zugriff auf die Data-Layer ist untersagt.
+- **Regel**: Darf ausschließlich die Logic Layer aufrufen. Ein direkter Zugriff auf die Data Layer ist untersagt.
 
 ### Logic Layer (`src/Logic`)
 - **Verantwortung**: Implementierung der Geschäftslogik und Orchestrierung von Prozessen.
@@ -18,7 +18,7 @@ Die Anwendung ist in drei strikt getrennte Layer unterteilt:
     - **BusinessQueries**: Spezifische Abfragen für geschäftsrelevante Daten.
     - **Manager**: Orchestratoren, die z.B. Caching-Strategien implementieren und zwischen verschiedenen Providern/Processoren vermitteln.
     - **Models**: Kernlogik-Objekte zur internen Verarbeitung innerhalb der Logic Layer.
-- **Regel**: Ist unabhängig von der UI-Layer und definiert die Anforderungen an die Data-Layer über Interfaces.
+- **Regel**: Ist unabhängig von der UI Layer und definiert die Anforderungen an die Data Layer über Interfaces.
 
 ### Data Layer (`src/Data`)
 - **Verantwortung**: Persistenz, Datenabruf und Kommunikation mit externen Systemen.
@@ -26,7 +26,7 @@ Die Anwendung ist in drei strikt getrennte Layer unterteilt:
 - **Komponenten**:
     - **Repositories**: Zugriff auf Datenbankentitäten.
     - **Entities**: Domain-Modelle für die Persistenz (spiegeln DB-Schema).
-    - **Provider / Processor Interfaces**: Definieren den Datenaustausch mit der Logic-Layer.
+    - **Provider / Processor Interfaces**: Definieren den Datenaustausch mit der Logic Layer.
     - **Mapper**: Transformation zwischen Entity und Business Model.
 - **Regel**: Kennt keine Geschäftslogik und ist nur für die Bereitstellung/Speicherung von Daten zuständig.
 
@@ -36,9 +36,9 @@ Die Anwendung ist in drei strikt getrennte Layer unterteilt:
 `UI Layer` $\rightarrow$ `Logic Layer` $\rightarrow$ `Data Layer`
 
 ### Kommunikationsregeln
-1. **Eintrittspunkt**: Die UI-Layer ruft immer einen UseCase, Workflow oder eine BusinessQuery in der Logic-Layer auf.
-2. **Orchestrierung**: Manager in der Logic-Layer organisieren den Zugriff (z.B. Cache-Check) und delegieren die eigentliche Arbeit an Provider- oder Processor-Interfaces der Data-Layer.
-3. **Entkopplung**: Die Logic-Layer sollte idealerweise gegen Interfaces der Data-Layer programmieren, um die Austauschbarkeit der Datenquelle zu gewährleisten.
+1. **Eintrittspunkt**: Die UI Layer ruft immer einen UseCase, Workflow oder eine BusinessQuery in der Logic Layer auf.
+2. **Orchestrierung**: Manager in der Logic Layer organisieren den Zugriff (z.B. Cache-Check) und delegieren die eigentliche Arbeit an Provider- oder Processor-Interfaces der Data Layer.
+3. **Entkopplung**: Die Logic Layer sollte idealerweise gegen Interfaces der Data Layer programmieren, um die Austauschbarkeit der Datenquelle zu gewährleisten.
 
 ## 3. Validierungsstrategie
 
@@ -82,7 +82,7 @@ Um eine hohe Codequalität und Wartbarkeit zu gewährleisten, wird eine pyramida
 
 ### Integration Tests (Data Layer)
 - **Fokus**: Korrekte Persistenz (Repositories, Processor) und Mapping.
-- **Regel**: Nutzen eine echte Test-Datenbank oder einen In-Memory-Speicher. Hier wird geprüft, ob die technische Implementierung der Data-Layer korrekt funktioniert.
+- **Regel**: Nutzen eine echte Test-Datenbank oder einen In-Memory-Speicher. Hier wird geprüft, ob die technische Implementierung der Data Layer korrekt funktioniert.
 
 ### Functional Tests (UI Layer & Scenarios)
 - **Fokus**: Durchlauf kompletter Business-Szenarien und Validierung von API-Endpunkten.
@@ -96,9 +96,6 @@ Für das System-Logging wird der PSR-3 Standard verwendet:
 - **Entkopplung**: Da es sich um ein Interface handelt, bleibt die Business-Logik unabhängig von der konkreten Implementierung (z.B. Monolog).
 - **Konfiguration**: Die Steuerung (Kanäle, Log-Level, Speicherorte) erfolgt rein über die Framework-Konfiguration, nicht im Code.
 
-## 8. Komponenten-Definitionen
-
-
 ## 8. Security & Autorisierung
 
 Die Absicherung der Anwendung erfolgt auf drei Ebenen: