Why you should stick to the default Laravel architecture

In the last days, I came across an increasing amount of posts on different ways how you can structure your software projects.

I'm part of the Laravel community, and the approach of these posts is mostly different from the default Laravel way. Their arguments are around structures based on business logic, working in large teams, and working on long-running projects. I think they are wrong, and they are solving a problem that doesn't exist.

Projects which are built by teams of developers and that take months to build, need to be easily maintainable. They should be easy to understand and follow as much default conventions as possible. Why? Teams change.

How do you prepare a project for changing teams? Stick to the most common standards and use boring technologies. So if you use Laravel, do not introduce an additional architecture on top of it. It takes more time to build this architecture, and every time a new developer joins the team, you need to teach your way of doing things. It takes time until they become productive, and if a deadline is near, you miss the opportunity of outsourcing a feature to a freelancer to get everything done in time. The custom architecture requires time to learn, and this is exactly the resource you don't have at this moment. Goal failed.

It's also wrong to think in business domains because that's not how your code works. It works in developer domains like models, views and controllers. That's why Laravel keeps it that simple. You don't need repositories, nested folder structures for classes of the same type, or the possibility to exchange every piece of technology at every moment. There is nothing wrong with a single directory of models or a controller directory that has 100+ files in it. Make sure you spend your time on naming, and you'll be fine. If things are properly named, they are much easier to find than if they are in a custom structure by feature. You need to guess which feature you have to look at and where to add your code. It's also not that clear when to create a new feature and when to add something to an existing one. Is a shopping cart an own feature or part of the checkout? There are reasons to split it, but there are also ones to keep them in one domain. Using the default way, you look for a CartController and a CheckoutController, which are in the same controllers directory. Done.

Keep things dead simple, and you won't struggle if you need to add features years after you have worked on the projects for the last time.