Enable Discovery debug logging for production troubleshooting
- Add DISCOVERY_LOG_LEVEL=debug - Add DISCOVERY_SHOW_PROGRESS=true - Temporary changes for debugging InitializerProcessor fixes on production
This commit is contained in:
226
docs/architecture/overview.md
Normal file
226
docs/architecture/overview.md
Normal file
@@ -0,0 +1,226 @@
|
||||
# Architekturübersicht
|
||||
|
||||
Diese Dokumentation bietet einen Überblick über die Architektur des Frameworks und erklärt die grundlegenden Konzepte und Designentscheidungen.
|
||||
|
||||
## Architekturprinzipien
|
||||
|
||||
Das Framework wurde nach folgenden Prinzipien entwickelt:
|
||||
|
||||
1. **Modularität**: Das Framework ist in unabhängige Module aufgeteilt, die einzeln verwendet oder ausgetauscht werden können.
|
||||
2. **Erweiterbarkeit**: Alle Komponenten sind so konzipiert, dass sie einfach erweitert oder angepasst werden können.
|
||||
3. **Testbarkeit**: Die Architektur ermöglicht einfaches Testen durch klare Schnittstellen und Dependency Injection.
|
||||
4. **Leistung**: Leistungsoptimierungen sind ein integraler Bestandteil des Designs, nicht nur eine nachträgliche Überlegung.
|
||||
5. **Sicherheit**: Sicherheitsmaßnahmen sind standardmäßig aktiviert und in die Kernkomponenten integriert.
|
||||
|
||||
## Schichtenarchitektur
|
||||
|
||||
Das Framework verwendet eine mehrschichtige Architektur, die eine klare Trennung der Verantwortlichkeiten ermöglicht:
|
||||
|
||||
```
|
||||
+-------------------+
|
||||
| Anwendung | <-- Anwendungsspezifischer Code (Controller, Models, Services)
|
||||
+-------------------+
|
||||
| Framework | <-- Framework-Komponenten (Routing, Validierung, Datenbank)
|
||||
+-------------------+
|
||||
| Infrastruktur | <-- Infrastrukturkomponenten (HTTP, Dateisystem, Cache)
|
||||
+-------------------+
|
||||
```
|
||||
|
||||
### Anwendungsschicht
|
||||
|
||||
Die Anwendungsschicht enthält den anwendungsspezifischen Code, der die Geschäftslogik implementiert. Diese Schicht umfasst:
|
||||
|
||||
- **Controller**: Verarbeiten HTTP-Anfragen und geben Antworten zurück
|
||||
- **Models**: Repräsentieren Geschäftsobjekte und Datenstrukturen
|
||||
- **Services**: Implementieren komplexe Geschäftslogik
|
||||
- **Repositories**: Kapseln den Datenzugriff
|
||||
|
||||
### Framework-Schicht
|
||||
|
||||
Die Framework-Schicht stellt die Kernfunktionalität bereit, die von der Anwendungsschicht verwendet wird. Diese Schicht umfasst:
|
||||
|
||||
- **Routing**: Leitet Anfragen an die entsprechenden Controller weiter
|
||||
- **Validierung**: Überprüft Benutzereingaben
|
||||
- **Datenbank**: Bietet Datenbankabstraktion und ORM-Funktionalität
|
||||
- **Authentifizierung**: Verwaltet Benutzerauthentifizierung und -autorisierung
|
||||
- **Caching**: Implementiert verschiedene Caching-Strategien
|
||||
|
||||
### Infrastrukturschicht
|
||||
|
||||
Die Infrastrukturschicht bietet grundlegende Dienste und Abstraktionen für die darüber liegenden Schichten. Diese Schicht umfasst:
|
||||
|
||||
- **HTTP**: Verarbeitet HTTP-Anfragen und -Antworten
|
||||
- **Dateisystem**: Bietet Abstraktionen für Dateisystemoperationen
|
||||
- **Cache**: Implementiert verschiedene Cache-Backends
|
||||
- **Logging**: Bietet Logging-Funktionalität
|
||||
- **Events**: Implementiert ein Event-System
|
||||
|
||||
## Anfragelebenszyklus
|
||||
|
||||
Der Lebenszyklus einer Anfrage im Framework durchläuft mehrere Phasen:
|
||||
|
||||
1. **Bootstrapping**: Die Anwendung wird initialisiert, Konfigurationen werden geladen und Dienste registriert.
|
||||
2. **Routing**: Die Anfrage wird an den entsprechenden Controller weitergeleitet.
|
||||
3. **Middleware**: Die Anfrage durchläuft die konfigurierten Middleware-Komponenten.
|
||||
4. **Controller**: Der Controller verarbeitet die Anfrage und gibt eine Antwort zurück.
|
||||
5. **Middleware (rückwärts)**: Die Antwort durchläuft die Middleware-Komponenten in umgekehrter Reihenfolge.
|
||||
6. **Antwort**: Die Antwort wird an den Client gesendet.
|
||||
|
||||
```
|
||||
+----------------+ +------------+ +------------+ +------------+ +----------------+
|
||||
| | | | | | | | | |
|
||||
| Bootstrapping | --> | Routing | --> | Middleware | --> | Controller | --> | Antwort senden |
|
||||
| | | | | | | | | |
|
||||
+----------------+ +------------+ +------------+ +------------+ +----------------+
|
||||
```
|
||||
|
||||
## Dependency Injection
|
||||
|
||||
Das Framework verwendet Dependency Injection (DI), um Abhängigkeiten zwischen Komponenten zu verwalten. Der DI-Container ist verantwortlich für:
|
||||
|
||||
1. **Registrierung**: Dienste werden im Container registriert.
|
||||
2. **Auflösung**: Der Container löst Abhängigkeiten automatisch auf.
|
||||
3. **Lebenszyklus**: Der Container verwaltet den Lebenszyklus von Diensten (Singleton, Transient, etc.).
|
||||
|
||||
Beispiel für die Verwendung des DI-Containers:
|
||||
|
||||
```php
|
||||
// Registrierung eines Dienstes
|
||||
$container->bind(UserRepositoryInterface::class, UserRepository::class);
|
||||
|
||||
// Auflösung eines Dienstes
|
||||
$userRepository = $container->get(UserRepositoryInterface::class);
|
||||
```
|
||||
|
||||
## Service Provider
|
||||
|
||||
Service Provider sind Klassen, die Dienste im DI-Container registrieren und konfigurieren. Sie bieten einen strukturierten Weg, um Komponenten zu initialisieren und zu konfigurieren.
|
||||
|
||||
Beispiel für einen Service Provider:
|
||||
|
||||
```php
|
||||
class DatabaseServiceProvider implements ServiceProviderInterface
|
||||
{
|
||||
public function register(Container $container): void
|
||||
{
|
||||
$container->singleton(ConnectionInterface::class, function () {
|
||||
return new Connection(config('database'));
|
||||
});
|
||||
|
||||
$container->bind(QueryBuilderInterface::class, QueryBuilder::class);
|
||||
}
|
||||
|
||||
public function boot(Container $container): void
|
||||
{
|
||||
// Initialisierungscode, der nach der Registrierung ausgeführt wird
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Ereignissystem
|
||||
|
||||
Das Framework implementiert ein Ereignissystem, das die Entkopplung von Komponenten ermöglicht. Das Ereignissystem besteht aus:
|
||||
|
||||
1. **Events**: Objekte, die Informationen über ein Ereignis enthalten.
|
||||
2. **Listeners**: Klassen, die auf bestimmte Ereignisse reagieren.
|
||||
3. **Dispatcher**: Verantwortlich für das Versenden von Ereignissen an registrierte Listener.
|
||||
|
||||
Beispiel für die Verwendung des Ereignissystems:
|
||||
|
||||
```php
|
||||
// Definieren eines Events
|
||||
class UserRegistered
|
||||
{
|
||||
public function __construct(public readonly User $user) {}
|
||||
}
|
||||
|
||||
// Definieren eines Listeners
|
||||
class SendWelcomeEmail implements ListenerInterface
|
||||
{
|
||||
public function handle(UserRegistered $event): void
|
||||
{
|
||||
// E-Mail an den neuen Benutzer senden
|
||||
}
|
||||
}
|
||||
|
||||
// Registrieren des Listeners
|
||||
$eventDispatcher->addListener(UserRegistered::class, SendWelcomeEmail::class);
|
||||
|
||||
// Auslösen des Events
|
||||
$eventDispatcher->dispatch(new UserRegistered($user));
|
||||
```
|
||||
|
||||
## Middleware-Pipeline
|
||||
|
||||
Das Framework verwendet eine Middleware-Pipeline, um Anfragen zu verarbeiten. Middleware-Komponenten können:
|
||||
|
||||
1. Anfragen vor der Verarbeitung durch den Controller modifizieren.
|
||||
2. Antworten nach der Verarbeitung durch den Controller modifizieren.
|
||||
3. Den Anfrage-/Antwort-Zyklus vollständig abbrechen.
|
||||
|
||||
Beispiel für eine Middleware:
|
||||
|
||||
```php
|
||||
class AuthenticationMiddleware implements MiddlewareInterface
|
||||
{
|
||||
public function process(Request $request, RequestHandlerInterface $handler): Response
|
||||
{
|
||||
if (!$this->isAuthenticated($request)) {
|
||||
return new RedirectResponse('/login');
|
||||
}
|
||||
|
||||
return $handler->handle($request);
|
||||
}
|
||||
|
||||
private function isAuthenticated(Request $request): bool
|
||||
{
|
||||
// Überprüfen, ob der Benutzer authentifiziert ist
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Konfigurationssystem
|
||||
|
||||
Das Framework verwendet ein flexibles Konfigurationssystem, das verschiedene Konfigurationsquellen unterstützt:
|
||||
|
||||
1. **Umgebungsvariablen**: Konfiguration über `.env`-Dateien.
|
||||
2. **Konfigurationsdateien**: PHP-Dateien, die Konfigurationsarrays zurückgeben.
|
||||
3. **Laufzeitkonfiguration**: Dynamische Konfiguration zur Laufzeit.
|
||||
|
||||
Das Konfigurationssystem unterstützt auch umgebungsspezifische Konfigurationen, sodass verschiedene Einstellungen für Entwicklung, Test und Produktion verwendet werden können.
|
||||
|
||||
## Erweiterbarkeit
|
||||
|
||||
Das Framework ist so konzipiert, dass es einfach erweitert werden kann:
|
||||
|
||||
1. **Interfaces**: Alle Kernkomponenten definieren Interfaces, die implementiert werden können.
|
||||
2. **Abstrakte Klassen**: Viele Komponenten bieten abstrakte Basisklassen, die erweitert werden können.
|
||||
3. **Hooks**: Das Framework bietet Hooks, an denen benutzerdefinierter Code ausgeführt werden kann.
|
||||
4. **Plugins**: Das Plugin-System ermöglicht die einfache Integration von Drittanbietercode.
|
||||
|
||||
## Sicherheitsarchitektur
|
||||
|
||||
Die Sicherheitsarchitektur des Frameworks umfasst mehrere Schichten:
|
||||
|
||||
1. **Eingabevalidierung**: Validierung aller Benutzereingaben.
|
||||
2. **Ausgabebereinigung**: Automatische Bereinigung von Ausgaben, um XSS zu verhindern.
|
||||
3. **CSRF-Schutz**: Schutz vor Cross-Site Request Forgery.
|
||||
4. **Authentifizierung**: Flexible Authentifizierungsmechanismen.
|
||||
5. **Autorisierung**: Rollenbasierte und fähigkeitsbasierte Zugriffskontrolle.
|
||||
6. **Web Application Firewall (WAF)**: Integrierte WAF zum Schutz vor gängigen Angriffen.
|
||||
|
||||
## Leistungsoptimierungen
|
||||
|
||||
Das Framework implementiert verschiedene Leistungsoptimierungen:
|
||||
|
||||
1. **Caching**: Mehrschichtiges Caching für Konfiguration, Routen, Views, etc.
|
||||
2. **Lazy Loading**: Komponenten werden erst geladen, wenn sie benötigt werden.
|
||||
3. **Kompilierung**: Views und Konfigurationen werden für schnelleren Zugriff kompiliert.
|
||||
4. **Pooling**: Verbindungspooling für Datenbanken und andere Ressourcen.
|
||||
5. **Optimierte Autoloading**: PSR-4-konformes Autoloading mit Optimierungen.
|
||||
|
||||
## Weitere Informationen
|
||||
|
||||
- [Komponenten](components.md): Detaillierte Informationen zu den Hauptkomponenten des Frameworks.
|
||||
- [Entwurfsmuster](patterns.md): Erläuterung der im Framework verwendeten Entwurfsmuster.
|
||||
- [Komponentendokumentation](../components/README.md): Dokumentation der einzelnen Komponenten.
|
||||
Reference in New Issue
Block a user