jens/symfony-architektur
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: update architecture guidelines for consistency and structure

Browse Source
This commit is contained in:
Jens Beckmann
2026-07-16 12:47:11 +02:00
parent 63ba220c04
commit 93363779a4
1 changed files with 8 additions and 11 deletions
Download Patch File Download Diff File Expand all files Collapse all files
architektur.md
+8 -11
View File
@@ -6,10 +6,10 @@ Dieses Dokument beschreibt die technische Architektur des Projekts. Es dient als
Die Anwendung ist in drei strikt getrennte Layer unterteilt: Die Anwendung ist in drei strikt getrennte Layer unterteilt:
### UI layer (`src/UI`) ### UI Layer (`src/UI`)
- **Verantwortung**: Präsentation, Handling von User-Input, API-Endpunkte, CLI-Commands. - **Verantwortung**: Präsentation, Handling von User-Input, API-Endpunkte, CLI-Commands.
- **Struktur**: Folgt einer domänenorientierten Struktur `src/UI/{Module}/{Interface}/{Feature}/...` (z.B. `src/UI/Sales/Http/OrderController.php`), um maximale Symmetrie zu den anderen Layern zu gewährleisten. - **Struktur**: Folgt einer domänenorientierten Struktur `src/UI/{Module}/{Interface}/{Feature}/...` (z.B. `src/UI/Sales/Http/OrderController.php`), um maximale Symmetrie zu den anderen Layern zu gewährleisten.
- **Regel**: Darf ausschließlich die Logic-Layer aufrufen. Ein direkter Zugriff auf die Data-Layer ist untersagt. - **Regel**: Darf ausschließlich die Logic Layer aufrufen. Ein direkter Zugriff auf die Data Layer ist untersagt.
### Logic Layer (`src/Logic`) ### Logic Layer (`src/Logic`)
- **Verantwortung**: Implementierung der Geschäftslogik und Orchestrierung von Prozessen. - **Verantwortung**: Implementierung der Geschäftslogik und Orchestrierung von Prozessen.
@@ -18,7 +18,7 @@ Die Anwendung ist in drei strikt getrennte Layer unterteilt:
- **BusinessQueries**: Spezifische Abfragen für geschäftsrelevante Daten. - **BusinessQueries**: Spezifische Abfragen für geschäftsrelevante Daten.
- **Manager**: Orchestratoren, die z.B. Caching-Strategien implementieren und zwischen verschiedenen Providern/Processoren vermitteln. - **Manager**: Orchestratoren, die z.B. Caching-Strategien implementieren und zwischen verschiedenen Providern/Processoren vermitteln.
- **Models**: Kernlogik-Objekte zur internen Verarbeitung innerhalb der Logic Layer. - **Models**: Kernlogik-Objekte zur internen Verarbeitung innerhalb der Logic Layer.
- **Regel**: Ist unabhängig von der UI-Layer und definiert die Anforderungen an die Data-Layer über Interfaces. - **Regel**: Ist unabhängig von der UI Layer und definiert die Anforderungen an die Data Layer über Interfaces.
### Data Layer (`src/Data`) ### Data Layer (`src/Data`)
- **Verantwortung**: Persistenz, Datenabruf und Kommunikation mit externen Systemen. - **Verantwortung**: Persistenz, Datenabruf und Kommunikation mit externen Systemen.
@@ -26,7 +26,7 @@ Die Anwendung ist in drei strikt getrennte Layer unterteilt:
- **Komponenten**: - **Komponenten**:
- **Repositories**: Zugriff auf Datenbankentitäten. - **Repositories**: Zugriff auf Datenbankentitäten.
- **Entities**: Domain-Modelle für die Persistenz (spiegeln DB-Schema). - **Entities**: Domain-Modelle für die Persistenz (spiegeln DB-Schema).
- **Provider / Processor Interfaces**: Definieren den Datenaustausch mit der Logic-Layer. - **Provider / Processor Interfaces**: Definieren den Datenaustausch mit der Logic Layer.
- **Mapper**: Transformation zwischen Entity und Business Model. - **Mapper**: Transformation zwischen Entity und Business Model.
- **Regel**: Kennt keine Geschäftslogik und ist nur für die Bereitstellung/Speicherung von Daten zuständig. - **Regel**: Kennt keine Geschäftslogik und ist nur für die Bereitstellung/Speicherung von Daten zuständig.
@@ -36,9 +36,9 @@ Die Anwendung ist in drei strikt getrennte Layer unterteilt:
`UI Layer` $\rightarrow$ `Logic Layer` $\rightarrow$ `Data Layer` `UI Layer` $\rightarrow$ `Logic Layer` $\rightarrow$ `Data Layer`
### Kommunikationsregeln ### Kommunikationsregeln
1. **Eintrittspunkt**: Die UI-Layer ruft immer einen UseCase, Workflow oder eine BusinessQuery in der Logic-Layer auf. 1. **Eintrittspunkt**: Die UI Layer ruft immer einen UseCase, Workflow oder eine BusinessQuery in der Logic Layer auf.
2. **Orchestrierung**: Manager in der Logic-Layer organisieren den Zugriff (z.B. Cache-Check) und delegieren die eigentliche Arbeit an Provider- oder Processor-Interfaces der Data-Layer. 2. **Orchestrierung**: Manager in der Logic Layer organisieren den Zugriff (z.B. Cache-Check) und delegieren die eigentliche Arbeit an Provider- oder Processor-Interfaces der Data Layer.
3. **Entkopplung**: Die Logic-Layer sollte idealerweise gegen Interfaces der Data-Layer programmieren, um die Austauschbarkeit der Datenquelle zu gewährleisten. 3. **Entkopplung**: Die Logic Layer sollte idealerweise gegen Interfaces der Data Layer programmieren, um die Austauschbarkeit der Datenquelle zu gewährleisten.
## 3. Validierungsstrategie ## 3. Validierungsstrategie
@@ -82,7 +82,7 @@ Um eine hohe Codequalität und Wartbarkeit zu gewährleisten, wird eine pyramida
### Integration Tests (Data Layer) ### Integration Tests (Data Layer)
- **Fokus**: Korrekte Persistenz (Repositories, Processor) und Mapping. - **Fokus**: Korrekte Persistenz (Repositories, Processor) und Mapping.
- **Regel**: Nutzen eine echte Test-Datenbank oder einen In-Memory-Speicher. Hier wird geprüft, ob die technische Implementierung der Data-Layer korrekt funktioniert. - **Regel**: Nutzen eine echte Test-Datenbank oder einen In-Memory-Speicher. Hier wird geprüft, ob die technische Implementierung der Data Layer korrekt funktioniert.
### Functional Tests (UI Layer & Scenarios) ### Functional Tests (UI Layer & Scenarios)
- **Fokus**: Durchlauf kompletter Business-Szenarien und Validierung von API-Endpunkten. - **Fokus**: Durchlauf kompletter Business-Szenarien und Validierung von API-Endpunkten.
@@ -96,9 +96,6 @@ Für das System-Logging wird der PSR-3 Standard verwendet:
- **Entkopplung**: Da es sich um ein Interface handelt, bleibt die Business-Logik unabhängig von der konkreten Implementierung (z.B. Monolog). - **Entkopplung**: Da es sich um ein Interface handelt, bleibt die Business-Logik unabhängig von der konkreten Implementierung (z.B. Monolog).
- **Konfiguration**: Die Steuerung (Kanäle, Log-Level, Speicherorte) erfolgt rein über die Framework-Konfiguration, nicht im Code. - **Konfiguration**: Die Steuerung (Kanäle, Log-Level, Speicherorte) erfolgt rein über die Framework-Konfiguration, nicht im Code.
## 8. Komponenten-Definitionen
## 8. Security & Autorisierung ## 8. Security & Autorisierung
Die Absicherung der Anwendung erfolgt auf drei Ebenen: Die Absicherung der Anwendung erfolgt auf drei Ebenen: