# 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.