Ziel dieses Teils
Ab hier wird es konkret.
Wir verlassen die reine Konzeption und bauen das
kleinstmögliche lauffähige System.
Noch keine Magie, keine Abkürzungen – nur:
- klarer Einstiegspunkt
- expliziter Bootstrap
- erste App-Struktur
4.1 Der Einstiegspunkt: public/index.php
Jede Anfrage beginnt an genau einer Stelle. Kein Auto-Magic, kein versteckter Dispatcher.
<?php
declare(strict_types=1);
require dirname(__DIR__) . '/vendor/autoload.php';
use App\\Bootstrap;
Bootstrap::boot();
Warum so schlicht?
Der Einstiegspunkt tut exakt eine Sache: Er übergibt die Kontrolle an den Bootstrap.
4.2 Bootstrap als bewusste Phase
Der Bootstrap ist keine Utility-Sammlung, sondern eine klar definierte Phase im Lifecycle.
<?php
namespace App;
use Core\\App;
final class Bootstrap
{
public static function boot(): void
{
$app = new App();
// Registrierung & Vorbereitung
self::register($app);
// Übergang in den kontrollierten App-Lifecycle
$app->run();
}
private static function register(App $app): void
{
// folgt in den nächsten Schritten
}
}
Wichtig: Nach run() gibt es kein Zurück.
Ab diesem Punkt gelten die Regeln des Systems.
4.3 App ≠ Framework
Die App ist kein Feature-Container,
sondern ein Shell-Objekt.
- sie kennt den Lifecycle
- sie orchestriert Router, Controller, Renderer
- sie besitzt keine Domain-Logik
<?php
namespace Core;
final class App
{
public function run(): void
{
// später:
// Middleware → Routing → Controller → Renderer → Response
}
}
Merksatz
Die App ist der Ablauf – nicht der Inhalt.
4.4 Warum wir hier noch nichts „können“
An diesem Punkt kann das System noch:
- starten
- kontrolliert laufen
- klar enden
Es kann bewusst noch keine Seiten, keine Controller, kein Routing.
Warum das wichtig ist
Jede Fähigkeit wird später explizit hinzugefügt – nichts entsteht implizit.
Übergang zu Teil 5
Jetzt existiert ein kontrollierter Systemrahmen.
In Teil 5 kommt die erste echte Entscheidung: Routing – und damit der erste Controller (inklusive Error-Controller als Standardweg).