L5 folder structure best practice

I use Services folder. So there will be App/Services/Commander, App/Services/Mailer etc

Concrete commands go to Commands folder. App/Commands/User ...

Some other examples: App/Hooks App/Models

Some keep their main services in App/ but this folder can quickly go too large and i hate large folders.

And i hate keeping all user related stuff in App/Users directory. I never find anything!

Once I start developing with Laravel 5, I'll most likely create a new folder in the app folder for all of my domain logic. Then, I'll put my Commands and CommandHandlers in separate namespaces, so it'd end up looking like this:

app/
    Cli/
        Foo/
            PurgeArchivedFoosConsoleCommand.php
            ImportFoosConsoleCommand.php
        SomeCliSpecificUtility.php
    Domain/
        Core/
            Services/
                SomeGenericService.php
        Foo/
            Commands/
                DoThingToFooCommand.php
                GenerateFooReportCommand.php
            Handlers/
                DoThingToFooCommandHandler.php
                GenerateFooReportCommandHandler.php
            Services/
                SomeFooSpecificService.php
            Foo.php
            FooRepository.php //interface
            FooReport.php
            SomeFooValueObject.php
    Infrastructure/
        Foo/
            EloquentFooRepository.php //implements FooRepository
    Http/
        Controllers/
            FooController.php
    Providers/
        DomainServiceProvider.php

Hi @thepsion5, thanks for your folder configuration sample. Only one question for Application Services and Domain Services where would you put them? And Event Listeners as Reporting or something similar?

If it's a service specific to a single context, I'd put it in a services folder, like app/Domain/Foo/Services/FooImportService.php. If it's generalized enough to apply to multiple contexts, I also have a app/Domain/Core namespace for things of that nature. I'll update my post to reflect that.

Yeah @thepsion5, very useful. Your DDD knowledge and how structure several Business Logic features on Laravel Application is very powerful. Maybe @JeffreyWay should allow you to collaborate with some DDD Lesson in the future :)

For smaller applications it can be kind of overkill. But I have to say, for the application I've been working on consistently for the past 8-9 months, it's REALLY good at keeping my code properly organized.

Yeah, for big applications some of the DDD features and the Command and Domain events are very useful not only for structuring your project, also for managing the behaviour of the entire application.

@thepsion5 thanks for that, thinks become clearer. Based on that structure, let's say we have integrated our application website and also the admin, how would you organize that?

Yeah @thepsion5, very useful. Your DDD knowledge and how structure several Business Logic features on Laravel Application is > > very powerful. Maybe @JeffreyWay should allow you to collaborate with some DDD Lesson in the future :)

+1 Jeffery is just awesome but it would be sweet to have somebody like thepsion5 to show up as a guest and present some outside contexts.

@israelOrtuno With commands, controlling access can be super-easy. I generally haven't dealt with super-complex access control rules, but I would define four classes:

1. An AclContainer interface to hold a set of ACL rules

2. An AclValidator to accept an to verify the current action is available for a given AclContainer

3. An AclCommand class that implements AclContainer

4. A command bus decorator that calls the AclValidator and throws an exception if an AclCommand fails to pass

I might also use separate views and controllers for admin sections, but as far as the domain folder structure goes it might not need to change at all.

@thepsion5 thanks for the response. What I meant is in terms of folder structure. My app is getting bigger as it's got the front website, a self-developed forum, and the backend for writing posts, user managing, etc... Those are the 3 entities I identify: Site, Forum and Office.

I was looking for a "standard" for this idea, but I think it's more of a project-preference issue. I've made a project where I just put them into a Models folder, but I also have a project where I have different namespaces and a folder for each (as an example, a Posts folder with a model class file for Posts, Comments, Tags, if that makes sense).

If it works for your project, do it.

I deleted my initial post as I worked out a solution within five minutes. My issue wasn't what to do, but how to do it - this forum and a Jeffrey Way's laravel 4 video explained in just a few minutes namespaces and a slight altering of composer.json - so cool. Very much the novice, I am still so early on the learning curve starting this brand new venture with Laravel 5.2 and Angular (I am an old man whose brain atrophied from being a long time vba hacker). I am succeeding in avoiding much of java script , but cannot escape some fundamentals.

I have a slightly different approach to structuring my apps. Basically, I like the idea of making your folder structure reflect the domain of your application and folders like "Http", "Commands", "Providers" etc. don't really do that. So my folder structure might look something like this (if I were building a blog for example):

/app
    /Users
        /Repositories
        /Listeners
        /Commands
    /Articles
        /Repositories
        /Helpers
        ...
    /Comments
        /Repositories
        ...
/modules
    /Blog
        /Controllers
        /Commands
        /Providers
        /Resources
            /assets
            /views
            /migrations
            ...
    /Dashboard
        /Controllers
        /Resources
        ...

So basically, the domain of the project is contained within the "app" folder (grouped by domain - everything about users is contained within the "Users" directory, everything about articles in the "Articles" etc.) and all of the framework specific logic (controllers, artisan commands, providers...) is contained within "modules" directory, where each module represents one endpoint of the application (front end, back end, public api, etc...)

But of course - to achieve this, I had to considerably modify the default Laravel app structure and I keep it in its own github repo as a starting point for every new project.

Thanks for the sharing - I very much agree with your approach. From the start the default Laravel framework has never seemed intuitive or logical to me. Knowing no better I first assumed the default structure was a stricture to be followed. I am happy to learn this is not so. Just another 'todo' to create a taxonomy suitable to the requirements of a quite complex business app.

@acasar I like your approach related to the folder structure.

I am starting new laravel application, can you share the important things to consider and also some examples.

Thanks :)

IMHO find a layout that makes sense to you. It really makes no difference.

Today's best practice is tomorrow's xkcd comic!

Today's best practice is tomorrow's xkcd comic!

Brilliant slogan! :D