It is even more useful to divide the logic into modules. Generally speaking, the module should have a set of classes with a narrow specialization. A well-designed module does not have to be a "universal combine".
For example, a security module has a narrow specialization - access security and application management security. Here should not be declared classes which translating messages into different languages, sending mail, writing logs, etc.
When a particular module is tied to a specific URL, it's also good practice, and it can also be considered as a "narrow specialization". For example, one module can process all HTTP requests to /api/users, another module can process /api/posts.
It is even more useful to divide the logic into modules. Generally speaking, the module should have a set of classes with a narrow specialization. A well-designed module does not have to be a "universal combine".
For example, a security module has a narrow specialization - access security and application management security. Here should not be declared classes which translating messages into different languages, sending mail, writing logs, etc.
When a particular module is tied to a specific URL, it's also good practice, and it can also be considered as a "narrow specialization". For example, one module can process all HTTP requests to
/api/users, another module can process/api/posts.