32 lines
1.7 KiB
Markdown
32 lines
1.7 KiB
Markdown
# 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.
|