3 crucial Laravel architecture best practices for 2024
Introduction to architecturing Laravel projects
How should you organize your Laravel app to best serve your needs? Well, the good news is that you don’t have to worry about this since you are using a framework! Stick to the defaults unless you have good and objective reasons to do otherwise.
And yet, people can’t stop overthinking the architecture of their projects.
To me, it seems that the urge to deviate from the standard project structure often reveals a deeper issue - a fundamental inability to maintain organization. Whether you adhere to the Laravel architecture or significantly modify it, the outcome is likely to be disorganized.
Therefore, to address this problem, we will put ourselves in shoes that would fit almost any enterprise project.
Before we begin, though, let’s define what an “enterprise project” is in our context. Essentially, it’s a public facing project with lots of users that generates revenue, making it vital to continuously evolve by adapting to new technologies, business requirements, and market trends.
Here’s what is expected from the team of such projects:
- Easy collaboration.
- Maximize compatibility with third-party solutions that will help maintain the cost of development down.
- Keep the cost of onboarding low. To achieve this, new hires need to easily find their way around the codebase, which can make them somewhat productive even when they lack domain knowledge.
With these goals in mind, let’s dive into what I, and most of the experts from the community, think are the best architecture practices.
Oh and before you continue, if you think you really need to go beyond what Laravel offers because you are working on big projects, let me introduce you to alternative ways of structuring applications taught by Martin Joe in his books “Microservices with Laravel” and “Domain-Driven Design with Laravel.”
Laravel architecture best practices
Keep the default folder structure
Using Laravel is meant to make your life easier, not harder.
- First, following conventions helps ensure that new hires can quickly find everything they need and start being productive as soon as possible. Laravel is a popular framework, and most developers will already be familiar with its default folder structure. By sticking to this, you help minimize the learning curve for new team members.
- Also, a profitable project is supposed to last for many years. People come and go. You will likely move on to something else. Why wouldn’t you make it easy for the ones who will take over?
- Additionally, by following the framework’s defaults, you ensure compatibility with many first and third-party packages. This can be crucial for maintaining development costs down and maximizing the use of available resources.
Organize by domain without breaking the folder structure
While it’s essential to keep the default folder structure, it’s also necessary to organize your code in a way that makes sense for your project. One way to do this is by organizing it by domain, without breaking the default folder structure.
This means that, for example, inside your Models folder, you could create a Blog folder. This way, when using the php artisan make:model Blog/Category command, the new file will be created at the right place.
This approach can also be used for controllers, middlewares, policies, and so on. Organizing your code the intended way will help you maintain a compatible, clean and intuitive codebase.
Don’t reach out for a package when Laravel already has a solution
Developers love discovering new ways of doing things, and it’s always tempting to experiment with new packages or approaches. This is fine for personal projects or when you are working alone, but it may not be ideal in a team setting.
When you hire Laravel developers, you are hiring them to expand and maintain your product using Laravel. It’s essential to remember this and stick to the built-in features of Laravel whenever possible.
For example, don’t use Data Transfer Objects (DTOs) instead of custom form requests unless there are good and objective reasons to do so. Using the built-in features of Laravel ensures that all developers on your team are working with the same set of tools and reduces the learning curve for new hires.
Don’t take my word for it, listen to the other experts
Matt Stauffer, who has a lot of experience building apps for enterprise as the CEO of Tighten, talks about how keeping things simple benefits big projects.
James Brooks is a core Laravel team member. He knows what working with a big team and a big codebase are. He also asked me to include it in this article, so there he is!
Want to know my #1 Laravel tip?
— James Brooks (@jbrooksuk) August 31, 2023
Follow the standards laid out by the skeleton and framework 👏
You'll find:
- Updates easier
- More packages will "just work"™
- New developers will grok your project quicker
- Life is just more enjoyable 🏄
Sebastian Schlein is the co-founder of BeyondCo, a company deeply involved with Laravel, and he also thinks that you should stick to the framework’s defaults. This is a tweet from 2019 by the way.
⚡️Why you should stick to the default @laravelphp architecture https://t.co/wfQ1Xl9eh4
— Sebastian Schlein (@seb_sebsn) October 21, 2019
Jason McCreary, from Laravel Shift, also showcases his favorite way of organizing Laravel projects. Looks familiar, don’t you think?
My ideal Laravel folder structure. Effortlessly elegant. 👀 pic.twitter.com/h0UYrnc6Xy
— Jason McCreary (@gonedark) November 30, 2020
All that being said, at the end, results matter the most. Here’s a tweet from Taylor Otwell himself about keeping an open mind:
I try not to express very strong opinions on how people structure or build their Laravel applications.
— Taylor Otwell ☁️ (@taylorotwell) June 13, 2023
I want to keep a strong culture of exploration and experimentation in the ecosystem. 👩🔬
