1.7 KiB
1.7 KiB
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,
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).
- Die UI kann auch als HA-REST-Consumer konsumiert werden (
- − 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.