Seems like overengineering for 95% of the apps out there.
I find many oop and design patterns add a lot of complexity with little to no benefit.
I am a big believer in YAGNI (you are not going to need it). Only implement design patterns when you have an immediate need of it, not just in case you might need it later or cause you want to just follow some best practice.
A big reason Laravel got so successful is because it makes things easy to read and keeps things simple.
I would say if you are working on some vendor package, or you are working in a very big team where you don't have influence on other development teams, then these oop and design patterns can be quite handy.
The architecture must support the use cases. [...] This is the first concern of the architect, and the first priority of the architecture.
If Laravel's native architecture can support your use cases, which is likely to be the case for small / mid size or early project, then yes, maybe you don't need Clean Architecture.
As the system's architect (apointed or de-facto) it is your responsibiliy to pick the best architecture you can given the project, its scope, its constraints, and its team.
If CA is overkill, then pick something simpler 👍 Just make sure you can migrate later as the project grows.
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.
Seems like overengineering for 95% of the apps out there.
I find many oop and design patterns add a lot of complexity with little to no benefit.
I am a big believer in YAGNI (you are not going to need it). Only implement design patterns when you have an immediate need of it, not just in case you might need it later or cause you want to just follow some best practice.
A big reason Laravel got so successful is because it makes things easy to read and keeps things simple.
I would say if you are working on some vendor package, or you are working in a very big team where you don't have influence on other development teams, then these oop and design patterns can be quite handy.
Thanks for your comment Bernard.
As I quote in the article
If Laravel's native architecture can support your use cases, which is likely to be the case for small / mid size or early project, then yes, maybe you don't need Clean Architecture.
As the system's architect (apointed or de-facto) it is your responsibiliy to pick the best architecture you can given the project, its scope, its constraints, and its team.
If CA is overkill, then pick something simpler 👍 Just make sure you can migrate later as the project grows.