I'm hoping this will make it easier to maintain the functionality and develop further
@longestdrive As someone who’s been down the road before, it actually makes things harder to develop and maintain. The idea of, “Everything will be modular so it will be easier” usually makes sense in theory, but then when you go down that road, it’s anything but.
When you split things into “modules” like this, you then start having to specify and maintain dependencies of versions. So if you have five packages, and you upgrade the version of Laravel you’re using from say, 7.x to 8.x, you now have to go and update the version constraints in each of your package’s composer.json files, otherwise you‘re going to get an “unsatisfiable requirements” error the next time you run composer update from your application.
Development also becomes a pain. Instead of being able to run php artisan make:model -mf in a Laravel application to create a model and a corresponding migration and factory class, you’re now going to have to do this by hand. Also, development moves from just creating files in your application, to having to create files in a package, commit that change, then run composer update in your application to get the latest package files unless you create a convoluted development environment using symlinks. So you lose the nice utilities that Artisan offers to create stubs and develop features quickly.
So as you can, my advice to the above is: “don’t”. Because the perceived benefits actually become significant drawbacks. There’s nothing wrong with having a Laravel application with lots of files. You can group your models in folders if you want to group them by “topic”, i.e. app/Models/Blog, app/Models/Shop, etc.