Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.

Rass's avatar
Level 1

How to structure multi dashboards folders and files?

Lets say I have these dashboards:

  • Admin dashboard
  • Student dashboard
  • Teacher dashboard

And there is the Front site where guests can see:

  • Front

Each dashboard has it own business logic. including the Front.

I was thinking of structuring it like this:

|- app/  
   |- Console/  
      |- Commands/  
   |- Events/  
   |- Exceptions/  
   |- Http/  
      |- Controllers/  
          |- Front/
          |- Admin/
          |- student/
          |- teacher/
      |- Middleware/  
   |- Jobs/  
   |- Listeners/  
   |- Providers/  
   |- Models
       |- User.php \ can be admin - student - teacher
       |- Lesson.php
       |- Article.php
       |- Role.php \ admin role - student role - teacher role 
       |- Permission.php
|- database/  
   |- factories/  
   |- migrations/  
   |- seeders  
|- config/  
|- routes/  
   |- front/  
   |- admin/  
   |- student/
   |- teacher/
|- resources/  
   |- assets/  
       |- front/  
       |- admin/  
       |- student/
       |- teacher/
   |- lang/  
       |- front/  
       |- admin/  
       |- student/
       |- teacher/
   |- views/
       |- front/  
       |- admin/  
       |- student/
       |- teacher/

but I don't know, since the app will be more and more bigger in the future, this seems very messy to me.

I am looking for something that can be maintainable, and when I want to change something or add some new feature I know where to look easily.

What the best practice to structure these folders and files? How will you structure something like this?

0 likes
3 replies
devfrey's avatar

I think your structure is perfectly fine. However, if there's going to be a significant difference in business logic between the domains (admin, student, teacher), it might be better to create namespaces at a higher level, allowing you to have a better distinction between the domains:

|- app/
   |- Admin
       |- Events
       |- Http
       |- ...
   |- Teacher
       |- Events
       |- ...
   |- Student
       |- ...

I would however keep the models, routes and resources as they are in your example.

Also, something I like to do is create an additional Foundation (or Common) namespace under App. This is where I would put my shared logic or more common cross-domain stuff, like exception handling and generic middleware.

Rass's avatar
Level 1

@devfrey Thanks for the info. It seems I might do it as you said.

For now, while searching.. I came a cross something called "modules", but I am having a hard time to understand how to structure this app as "modules", and if its a good idea to structure it as modules?

devfrey's avatar

@RASS - "Modules" can mean anything, really. I wouldn't stick to that terminology. Structure an application the way you think works best for you (and/or your team).

Please or to participate in this conversation.