Laravel application structure

You can have a look at the Repository Pattern to have 'thin controller, fat model' as well as grouping functionalities. It totally depends on projects to projects so I don't think there are any rules for a better structure.

I would love to hear from others as well.

Cheers !

I'd go for a folder by feature structure (and then by type if needed), if you have too many files in the folder by type structure currently offered by Laravel 5.

Example:

Folder By Feature Structure:

- app
     - Acme (This folder could be the name of the project or the name of the company)
       - Users
       - Reporting
       - Billing
       - Analytics
       - Customers
       - Companies
       - Invoices
 - Http
 - Providers

In these folders by feature, you would have all of your service classes, events, listeners, models, custom exceptions, mailer classes etc.

As for the controllers part, you could still put them into a feature folder if you have multiple controllers as part of a bigger feature

Example:

- app
    - Http
        - Controllers
            - Auth
                 - LoginController.php
                 - RegisterController.php
                 - ForgotPasswordController.php
            - CustomerSupport
                 - SupportTicketsController.php
                 - SupportConversationsController.php
                 - SupportInvitationsController.php

I would like to recomend you to read about Modules and DDD (Domain-Driven-Design). After you understand the theory behind those architectures, you can use it, adapting for the needs of your project.

I faced that same issue, just a month ago. I started to have too many files, and the default organization of folders became a hell for me. I decided to follow the DDD architecture, but sometimes DDD can be massive, mainly for small to medium applications. So i adapted it, to be more simple, at least for now...

I considered creating my architecture based on Modules too, but I thought it will not fit perfectly for the project.

I'm also using the Repositories Pattern, together with DDD, yes! It's completely possible to mix all patterns you REALLY NEED! (make sure you really need it before implementing, cause those patterns come with complexity for your software).

There is a lot of software architecture and archtypes patterns (and philosophies), you can use MVC together with DDD or SOA (Services Oriented Architecture), and Repositories with Active Record (the Eloquent), and etc etc etc.

@ricardovigatti Great! Do you have a great book/site/article about it?

@Ruffles that's what I'm going to do. But how would my namespace look in for example the Billing directory? What do I've to add to the composer.json file for autoloading? (PSR-4)

Repositories are not a magic bullet for making code more manageable. They in fact have the opposite effect in 99% of cases.

@lars64 I like to take a “domain” driven approach where I’ll group my entities based on their part in the application. Not everything neatly fits into “MVC” folders as you’ve found.

For example, one of my side projects is a video on demand website. Its structure, simplified, looks something like this:

• /app
  • /Billing
    • Invoice.php
    • Transaction.php
  • /Catalog
    • Episode.php
    • Series.php
    • Title.php
  • /Http
    • /Controllers
      • All my controllers
  • /Media
    • Bookmark.php
    • Chapter.php
    • Encoding.php
    • TranscodingJob.php
    • Video.php
  • /Subscriptions
    • Plan.php
    • Subscription.php

That isn’t every file/directory, but should illustrate that not every model has to be stuffed in a folder called “Models”.

@martinbean very helpful thanks for your time. Also found this video on Laracasts https://laracasts.com/lessons/where-do-i-put-this

My very rough rule of thumb is that if I'm having to scroll up & down or spend more than a second or two trying to find a file in a folder, then it's time to break things up to a more modular layout. Depending on the project, that's sometimes by feature, sometimes by 'thing', sometimes just by 'something that feels right' :-)

You don't have to add anything to composer.json. Everything is PSR 4 autoloaded so your namespace would look something like:

namespace  App\Acme\Billing;

use App\Acme\Billing\SomeClassForBilling;

@lars64 , i don't have any sites or articles in mind for now. About modules in Laravel, there is a tons of packages. I never get into testing them, but those two seems to be good: https://github.com/pingpong-labs/modules and https://github.com/caffeinated/modules.

DDD is a complex subject, so there is some books about it: Domain Driven Design by Eric Evans is a classic, https://www.amazon.com/Domain-Driven-Design-Tackling-Complexity-Software/dp/0321125215. After, you can try this one: https://leanpub.com/ddd-in-php

@Ruffles

I like your example:

     - Acme (This folder could be the name of the project or the name of the company)
       - Users
       - Reporting
       - Billing
       - Analytics
       - Customers
       - Companies
       - Invoices
 - Http
 - Providers

Where do you suggest to to put Repositories classes and Repositories Interface classes?

For example Customers and Invoices folders require to access to UserRepository .php

Where do you store model classes? What if Reporting and Analytics share shame model class?

This structure is more of a general structure, so I'd say put Models, Repositories, Services, Interfaces, Jobs, Listeners, Events in the feature folder they belong to based on the context (for example Users) and just use the classes wherever you need them.