Backend & web applications
Task Management System · Symfony
The Symfony and Doctrine domain model of an app where a team organises its work: a user hierarchy, projects, tasks, notifications and typed business values.
- Focused on the domain model
- Individual project
- Doctrine entities
- 7
- native PHP enums
- 4
- user subtypes (JOINED)
- 3
01Starting point
Context & mission
The problem
In a task management app, almost every bug comes from a poorly designed model: roles as free strings, inconsistent statuses, fuzzy relations.
The mission
Lay down a solid domain model first, before screens and workflows.
My role
A personal project, separate from the confidential application I built during my 2024 ALTEN internship, despite a similar subject.
02Execution
What I did
User hierarchy
A base Utilisateur entity and three subtypes (Admin, Manager, User), mapped with Doctrine’s JOINED inheritance.
Projects and tasks
A project has a description, deadline, status and its tasks; a task has a deadline, status, priority, project and assigned user.
Typed business values
Four native PHP enums: role, project status, task status and priority.
Notifications
A Notification entity linked to the user, the foundation for future notification workflows.
03Design
Architecture
Symfony 5.4 and Doctrine ORM: entities, enums, repositories and versioned migrations. Application workflows will come next on top of this model.
- UserAdmin · Manager · User
- ProjectStatus · deadline
- TaskStatus · priority
- Notification
- PHP enumsRole · statuses · Priority
- DoctrineJOINED · migrations
04Impact
Results
- A complete, typed domain model, ready for workflows.
- A schema versioned with Doctrine migrations.
05Wrap-up
Takeaways
What this project provesThat I start with the model: inheritance, relations and typed values set before the first view.
06Technology
Full stack
- PHP 8.1
- Symfony 5.4
- Doctrine ORM
- Doctrine Migrations
- MySQL
- PHP enums
- Twig