Don't overthink your application architecture

Laravel offers many different ways to structure your application. It's very flexible in that regard.

That being said, there tends to be commonly-accepted conventions or defaults that are recommended when you read the documentation.

But it's tempting when we start building an app to think ahead and try to envision our grand future and take that into account with our architecture.

For example, maybe we believe we're eventually going to have hundreds of thousands of users, so we worry about performance or how we might want to scale things independently.

That could lead us down a path which not only deviates from the defaults, but adds complexity and slows us down, long before we will receive any benefit from that approach.

Instead, my approach is to not overthink my architecture. I start with Laravel's defaults and conventions, and only adopt additional patterns as I find they solve actual problems in my project.

At times, I will see some new approach and wonder if it's better than what I'm doing, but I don't pull it into my production code.

I like experimenting in fun projects, but for real production code, I like boring where possible.

One final point: Notice I said not to "overthink" your architecture. I'm not saying "don't think at all" about your architecture. There's a big difference.

Deviate from defaults where necessary and where beneficial, just don't rush into it because it might be better in some future scenario that may not happen for years, if at all.

Here to help,

Joel

P.S. Would you like some help thinking through big architecture decisions on your application? A second opinion could save you a lot of effort.