I use Laravel very often, but I use it for what Taylor intended it to be; an Application Framework. In this context "Application" is not the system nor the solution, it is the application of the system or the solution.
Application is where or how something is applied. In this case, how the system is used to the web. The framework (in this case) provides access control to the system via Auth, ACL. In the case of Laravel, it also helps with bootstrapping, dependency injection, environment variables, etc.. You know things your application needs but not things that your business logic needs.
A common mistake and a terrible one for that matter are devs either placing logic in "HTTP" Controllers (I mean HTTP Controllers. The name says it all) or in database abstraction layers (Again, DBAL/Eloquents purpose is very well documented). It is so simple to notice that having logic tied to a database or even if it is an abstraction such as Eloquent, you will be reading from the persistent storage every time you need to check a condition.
There's no need for that, and that is not why we have functions and variables -> processors and RAM.
Regarding my article, I want to point out that I'm not saying that all systems need to implement a PoEAA. However, if your system implements the OOP paradigm, then, I will say that it must follow the SOLID principles.
Also, Laravel (for example) is built with this in mind. Why does Laravel offer Interface to Concrete binding out of the box if we are depending on concrete classes?
Eloquent's job is to abstract SQL and not to create some sort of fluent query language for business rules. I can go on forever..another example I see very often...
Users are not Members, nor they are Clients. Users are merely people (or systems) with access to the application. A Member cannot suddenly update their name. It is sporadic for someone to change their name in the real world and I'm sure that most systems need to have real people's names. Same for address. Update address does not mean the Member moved house but that the House suddenly changed its name or location. This hardly ever occurs in real life!
This is a serious matter. This year (2019), I have worked with a client who because of these mistakes by their Engineering team, completely screwed the whole SaaS. The damage to their reputation was so bad that they ended starting from scratch, new name, new brand, new marketing. They've lost 2 years of hard work because the system could not grow, the team did grow but made it all worst because the CTO was only looking for Laravel and VueJS devs and not enterprise devs or engineers.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
We all think it, but you said it :)
To add more to your valid points:
I use Laravel very often, but I use it for what Taylor intended it to be; an Application Framework. In this context "Application" is not the system nor the solution, it is the application of the system or the solution.
Application is where or how something is applied. In this case, how the system is used to the web. The framework (in this case) provides access control to the system via Auth, ACL. In the case of Laravel, it also helps with bootstrapping, dependency injection, environment variables, etc.. You know things your application needs but not things that your business logic needs.
A common mistake and a terrible one for that matter are devs either placing logic in "HTTP" Controllers (I mean HTTP Controllers. The name says it all) or in database abstraction layers (Again, DBAL/Eloquents purpose is very well documented). It is so simple to notice that having logic tied to a database or even if it is an abstraction such as Eloquent, you will be reading from the persistent storage every time you need to check a condition.
There's no need for that, and that is not why we have functions and variables -> processors and RAM.
I also wrote about this topic here: keith-mifsud.me/blog/start-a-new-p....
Also, Laravel (for example) is built with this in mind. Why does Laravel offer Interface to Concrete binding out of the box if we are depending on concrete classes?
Eloquent's job is to abstract SQL and not to create some sort of fluent query language for business rules. I can go on forever..another example I see very often...
Users are not Members, nor they are Clients. Users are merely people (or systems) with access to the application. A Member cannot suddenly update their name. It is sporadic for someone to change their name in the real world and I'm sure that most systems need to have real people's names. Same for address. Update address does not mean the Member moved house but that the House suddenly changed its name or location. This hardly ever occurs in real life!
This is a serious matter. This year (2019), I have worked with a client who because of these mistakes by their Engineering team, completely screwed the whole SaaS. The damage to their reputation was so bad that they ended starting from scratch, new name, new brand, new marketing. They've lost 2 years of hard work because the system could not grow, the team did grow but made it all worst because the CTO was only looking for Laravel and VueJS devs and not enterprise devs or engineers.