Doku: ADR-007 + konkrete Architektur (Layer, Naming, Patterns, Tests)

Doku/adr/007-architekturrichtlinien.md

@@ -0,0 +1,31 @@
+# 007 – Architekturrichtlinien
+
+**Status:** accepted
+
+**Kontext.** Das Projekt soll eine moderne Symfony-Anwendung mit sauberer
+schichtbasierter Architektur haben. Als Referenz dient das interne Repo
+[`jens/symfony-architektur`](https://git.ljh31.de/jens/symfony-architektur),
+dort insbesondere `architektur.md` (13 Sektionen) und `AGENTS.md`.
+
+**Entscheidung.** Die Codebasis unter `src/` wird in genau drei primäre
+Layer gegliedert, strikt nach Abhängigkeitsrichtung (UI → Logic →
+Interface → Data-Implementierung):
+
+- **`src/UI`** – Controller, Formulare, Templates, Twig-Views, HTTP-Adaption.
+- **`src/Logic`** – Reine PHP (keine Framework-Abhängigkeiten). UseCases für
+  Writes, Querien für Reads, Manager pro Model, Provider-/Processor-Interfaces,
+  Models, DTOs, Domain-Exceptions, Event-Veröffentlichung.
+- **`src/Data`** – Doctrine-Entities, Provider-/Processor-Implementierungen,
+  Mappers, Transaction-Manager-Bridge, Bridge zum Symfony EventDispatcher.
+
+**Konsequenzen.**
+- + Business-Logik ist 100 % framework-unabhängig und in Unit-Tests ohne Kernel lauffähig.
+- + Data-Implementierungen sind austauschbar; z. B. SQLite ↔ Postgres nur im Data-Layer.
+- + Die UI kann auch als HA-REST-Consumer konsumiert werden (`/api/today`, `/api/dishes`).
+- − Mehr Boilerplate als eine anemic-Entity-Architektur; kompensiert durch
+      konventionelle Naming- & Verzeichnis-Regeln und Symfony-Autowiring.
+- − Symfony-Forms nutzen wir **nicht** (htmx + eigene Validierung aus ADR-002
+      bleibt; Forms wären eine zusätzliche Framework-Abhängigkeit, die gegen
+      die UI-Logik-Regel in der Referenz-Architektur verstoßen würde). Wir
+      validieren im Controller per reinem PHP, wie Sektion 4 der Referenz das
+      vorsieht.