Is the described architecture bad for laravel?

Question

Laravel

Good afternoon. I will describe the architecture that I want to make:
break the whole project into packages (modular architecture), and expand the system in the form of packages. each package can have its own architecture (but the MVC standard) - why is that - if you need to fix something, then go to a specific folder and edit there. no need to spread the code, one large element, throughout the framework. Further, all shared resources (models through which connections are created in the database, i.e. eloquent) are located in some kind of shared folder. and all packages have access to them, while all business logic is hidden in packages, and in general models there are only connections to the database, and no logic.
I pursue the goal of making the system incoherent as much as possible.
Why is this worse than the approach - when all the logic is located in services, and in general, why is this approach bad?

Answer 1

What do you mean by packages?
The fact that the framework generates Controller Model View folders by default does not mean that it is necessary to use them in this form. Divide the project into logical modules, allocate modules to separate folders with their models and controllers.
Making 3 dump folders with controllers/models/views is a very bad idea in terms of navigation control of connectivity and dependencies between modules
See Project Structure
The logic in services is more connected than a normally designed domain model.
For business logic in services, see Anemic Domain Model
MVC is not a standard and this abbreviation has nothing to do with the folder structure

Answer 2

Why is this worse than the approach - when all the logic is located in services, and in general, why is this approach bad?

He is no worse and no better. Packages are one thing, services are another, and for some reason you "put them in one basket". What is the essence of a package? - a package is a certain module that solves a specific task, supported and maintained by a specific vendor. For the most part, packages are in no way tied to where and how they will be used. That is, a package is a set of common logic, processes, etc. to solve some problem (or a set of similar / related tasks), for example, for image processing.
A service or some other part of the application is part of a specific (your) application , that is, something that is written and intended specifically for this application, and not for a universal solution to common problems. The package is the logical opposite of this.
Do not forget that the more universal a solution is (like a "Swiss knife"), the worse it solves a specific problem. The same applies to what you are describing. If you make some universal solutions and put them into packages:
1. Lose the expressiveness of solutions
2. Lose productivity
3. Get many applications (packages) for servicing instead of one specific
If you are going to put not "universal solutions" into packages, but " dot" - in my opinion, this is the worst possible option, since it will still be the same "code smearing", only removed to another folder, out of sight, plus all the charms associated with package maintenance will be added to this.
"Don't shit in code" is an art and experience that no "package" can replace.

Answer 3

In words, the modular architecture sounds good, but in fact, over time, everything merges into highly dependent modules from each other, and complex support. Monolith is easier to maintain. On several projects, I had to rewrite due to the complexity of supporting from modular to multiloit.

Answer 4

Package names?