Das Aufgaben-Manager-Projekt vorstellen
Das Aufgaben-Manager-Projekt vorstellen
~11 Min. Lesezeit Zuletzt aktualisiert am 8. August 2026
Bevor wir in Block 2 mit Routing beginnen, ein detaillierter Blick auf das Domänenmodell unseres Projekts – die Struktur, an der wir ab jetzt bis Kapitel 49 durchgehend arbeiten.
Das Domänenmodell
Vier zentrale Konzepte, die wir schrittweise als Doctrine-Entities (Block 4) modellieren werden:
- User – ein registrierter Nutzer, kann Mitglied mehrerer Projekte sein.
- Project – ein Arbeitsbereich mit einem Namen, gehört EINEM Eigentümer (
User) und hat MEHRERE Mitglieder. - Task – eine einzelne Aufgabe innerhalb eines
Projects, mit Titel, Status (offen/in Arbeit/erledigt), Fälligkeitsdatum, und einem zugewiesenenUser. - Comment – ein Kommentar eines
Users zu einemTask.
Die Beziehungen im Überblick
Beziehungen zwischen den vier Kern-Entities
User (1) ──────owns─────── (n) Project User (n) ────member of──── (n) Project [ManyToMany] Project (1) ────has──────── (n) Task User (1) ───assigned to──── (n) Task Task (1) ───────has──────── (n) Comment User (1) ──────writes────── (n) Comment
Diese Beziehungsvielfalt ist ABSICHT: OneToMany/ManyToOne (Kapitel 22) und ManyToMany (Kapitel 23) kommen BEIDE im selben Projekt natürlich vor, statt künstlich für ein Lehrbeispiel konstruiert zu werden.
Welche Features wir Block für Block bauen
- Block 2 (Routing/Controller): Projekt- und Aufgabenlisten anzeigen.
- Block 3 (Twig/Formulare): Projekte und Aufgaben über Formulare anlegen/bearbeiten.
- Block 4 (Doctrine): alle vier Entities mit ihren Beziehungen, Datenbank-Persistenz.
- Block 5 (Security): Registrierung, Login, Zugriffskontrolle (nur Projekt-Mitglieder sehen Projekt-Inhalte).
- Block 6 (Services/Events): Benachrichtigungen bei Aufgaben-Zuweisung, E-Mail-Versand.
- Block 7 (Console/Testing): Erinnerungs-E-Mails für überfällige Aufgaben per Cron-Command, automatisierte Tests für die Kernlogik.
- Block 8 (Caching/Deployment): Dashboard-Statistiken cachen, produktionsreif machen.
Tipp: Dieses Kapitel dient als STÄNDIGE Referenz – kommen Sie in späteren Kapiteln zurück, wenn Sie sich fragen, WARUM eine bestimmte Entity oder Beziehung so modelliert ist, wie sie ist.