diff --git a/architektur-patterns.md b/architektur-patterns.md
index 46a3729..ea78b93 100644
--- a/architektur-patterns.md
+++ b/architektur-patterns.md
@@ -1,5 +1,13 @@
 # Architektur Patterns
 
+## 0. Interface-Richtlinien
+Um Konsistenz und Dependency Inversion zu gewährleisten, gelten folgende Regeln für alle Interfaces:
+
+- **Namenskonvention**: Zwingendes `Interface`-Suffix (z.B. `OrderProviderInterface`, `ShippingManagerInterface`).
+- **Ort & Abhängigkeit**: Das Interface liegt zwingend dort, wo es *gebraucht* wird – also meist im `src/Logic` Layer. Die Implementierung in der Data-Schicht hängt vom Logic-Vertrag ab. Dadurch bleibt die Business-Logik unabhängig von Infrastrukturdetails.
+- **Ausnahme: UseCases & Queries**: Diese erhalten bewusst kein eigenes Interface. Da ein UseCase eine konkrete fachliche Operation darstellt und es selten mehrere Implementationen derselben Aktion gibt, bringt DI hier nur Boilerplate ohne Mehrwert. Der Vertrag allein durch PHP-Typisierung ausreicht.
+  - *Strategische Ausnahme:* Wird das **Strategy-Pattern** benötigt (z.B. A/B-Testing oder unterschiedliche Logiken pro Kunde), kann gezielt ein Interface für den UseCase erstellt werden.
+
 ## 1. UseCase Pattern (`src/Logic`)
 
 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.