Conhecer Design Patterns ajuda muito a pensar nesta organização, mas para te dar um direcionamento, posso dizer que gosto muito da organização dos projetos Laravel, resumidamente:
- APP - pasta para a lógica da aplicação
- HTTP - onde as requisições http serão tratadas, Controllers, Middlewares ...
- Console - onde os comandos de terminal serão escritos
- Models - para os modelos, se você usa o ORM padrão chado Eloquent
- Suas pastas, eu crio uma pasta Services, outra Repositories, e assim por diante
- database - lógica de manutenção do banco de dados, seed, migrations, factories
- config - arquivos com as configurações da aplicação
- resources - aqui encontramos Views quando o front é desenvolvido no mesmo codebase, entre outras pastas logicamente organizadas para gerenciar recursos como assets, docs, etc
- route - roteamentos
- storage - arquivos temporários, caches, logs
- tests - testes
- vendor - dependências
- public - ponto de entrada e arquivos públicos para o front
Eu gosto de, dentro desta separação por funcionalidade ou por contexto técnico, criar subpastas para módulos quando a aplicação é muito grande, por exemplo: Http/Controllers/Vendas, onde os controladores de Vendas existirão. Mas tem algumas equipes que preferem criar uma pasta de módulo e dentro dela replicar toda a estrutura da organização, algo assim: Vendas/Http/Controllers, Vendas/Console, Vendas/Models, etc.
Essa é apenas uma sugestão muito superficial, pois não existe a melhor nem a mais correta organização de pastas. O ideal é uma padronização que possua alguma lógica, documentada, e seguida por toda a equipe.
Se quiser dá uma olhada nos artigos sobre Laravel no meu blog, e acompanha lá por quê estou criando material PHP e Laravel frequentemente.