Before starting routing in block 2, a detailed look at our project's domain model – the structure we'll continuously work on from now through chapter 49.

The domain model

Four central concepts, which we'll gradually model as Doctrine entities (block 4):

• User – a registered user, can be a member of several projects.
• Project – a workspace with a name, belongs to ONE owner (User) and has SEVERAL members.
• Task – a single task within a Project, with a title, status (open/in progress/done), due date, and an assigned User.
• Comment – a comment by a User on a Task.

The relationships at a glance

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

This relationship variety is DELIBERATE: OneToMany/ManyToOne (chapter 22) and ManyToMany (chapter 23) BOTH occur naturally in the same project, instead of being artificially constructed for a teaching example.

What features we build, block by block

1. Block 2 (routing/controllers): displaying project and task lists.
2. Block 3 (Twig/forms): creating/editing projects and tasks via forms.
3. Block 4 (Doctrine): all four entities with their relationships, database persistence.
4. Block 5 (security): registration, login, access control (only project members see project content).
5. Block 6 (services/events): notifications on task assignment, sending emails.
6. Block 7 (console/testing): reminder emails for overdue tasks via a cron command, automated tests for the core logic.
7. Block 8 (caching/deployment): caching dashboard statistics, becoming production-ready.