The thing with "managers" is that they "manage" a lot of stuff. So maybe you are tempted to create a:
The problem with this, in my opinion, is that this file will accumulate a lot of logic over time. It could become a very big file with all the rules overlaping each other, making it difficult to maintain. I don't know if this is the official name for it, but I call it "bottleneck".
I've found that a simple solution to this problem is separating small staff in it's own structure. Each "operation" in a separate structure.
The level of separation is up to you. They could be separate classes, separate files, and so on. The level os separation is a decision you have to make based on your needs. I like separate files because you won't get distracted by "old code" when you're making new stuff.
This structural separation of concerns is very important so your system doesn't become fragile over time. Think of systems where you fix something in a feature and break another. Also...you should be writing tests.
Be ware of your directories too. Popular "MVC" frameworks tend to give you predefined directories to work on, which doesn't scale very well. As the app grows, the directories also grow. This is also a bottleneck. You should identify and try to avoid all bottlenecks in your app.
A solution I've found that works for me is grouping small groups of functionallity in it's own directory. So the user related files could be grouped in a "users" directory, for instance.
These seem like simple advices but they have a huge impact on system health over time. I found out in the worst way that architecture matters, big time.