01-07-2016
Let me start by saying Laravel is an amazing framework. However when it comes to writing more complex and bigger applications, I find the default structure laravel comes with cumbersome and not ideal.
The way the default laravel installation comes with is basically all the application logic inside an app/ folder. This works, but I would not suggest going this route.
Just imagine having a medium sized applicated where everything is in the app/ folder, worse, every model is in the root of the app folder! At some point you will spend a lot of time looking for things because everything is bunched together.
Enter the modular world
This is what being modular is trying to resolve. You split of the business logic into different parts, which belongs together. If you're into Domain Driven Design, you can consider a module an aggregate.
Every module has its own routes/controllers/models/views/business logic/etc. Meaning every module contains a group of classes that all are related to each other in some way.
Example
Consider an application where you'd have products and a shopping cart. To keep it simple.
You would have something like this:
app/
- Http
- Controllers
- Admin
- ProductsController
- ProductCategoryController
- OrderController
- OrderStatusController
- Frontend
- ProductsController
- CartController
- CartAddressController
- CartPaymentController
- CartReviewController
- CartSuccessController
- ...
- Requests
- CreateProductRequest
- UpdateProductRequest
- CreateProductCategoryRequest
- UpdateProductCategoryRequest
- CreateAddressRequest
- UpdateAddressRequest
- ...
- Middleware
- HasCartItem
- routes.php
- Models
- Product
- ProductCategory
- Cart
- CartItem
- User
- UserAddress
- Order
As you can see I'm leaving a lot of classes out or this would be a lot bigger. We're not even covering repositories, views, service classes and more. Even this few classes already show that application is becoming a mess. Applications also have more than just products and carts, so the mess would be even worse.
Now lets see what this could look like with a modular approach.
Modules/
- Cart
- Http
- Controllers
- Frontend
- CartController
- CartAddressController
- CartPaymentController
- CartReviewController
- CartSuccessController
- Requests
- CreateAddressRequest
- UpdateAddressRequest
- Middleware
- HasCartItem
- adminRoutes.php
- frontendRoutes.php
- Models
- Cart
- CartItem
- Repositories
- resources
- lang
- views
- Product
- Http
- Controllers
- Admin
- ProductController
- ProductCategoryController
- Frontend
- ProductController
- adminRoutes.php
- frontendRoutes.php
- Requests
- CreateProductRequest
- UpdateProductRequest
- CreateProductCategoryRequest
- UpdateProductCategoryRequest
- Models
- Product
- ProductCategory
- Repositories
- resources
- lang
- views
With this structure, everything that belongs together is grouped into one namespace. This also means that you don't end up with one huge routes file for instance.
When you need to find something, you directly know where to search, in which folder you can dig through.
Granted, there are more folders, but it has the advantage of being clear at a birds eye view. Uncle Bob has a good video about architecture on why keeping everything in app/ isn't a good idea.
Modules in Laravel
Now you must be thinking how do I implement this in laravel ? At its basics it's fairly easy, you can just autoload the Modules folder using PSR-4 and be done with it.
However that leaves more work to you to register the custom view/lang/config namespaces, being able to have migrations in each module and run migrations of an individual module. Having frontend assets per module, and having a quick way to publish them to the public/ directory. Also an easy way to access to correct asset based on a given module name. etc. etc.
TL;DR, there is a lot more than just PSR-4 autoloading if you want to be productive using this method, and want to have a lot of convience methods availabel to you.
That's where the package Laravel-modules comes in.
This package will give you the ability to have custom namespaces for views, config, and languages. Handling migrations/seeds per module. Assets management per module. Helper convience methods. And so much more.
This package is what AsgardCMS uses behind the scenes to achieve its modular approach.
One more thing
To top it all of, every module can be considered as a composer package. Meaning you can re-use your modules on other projects and handle its versioning easily.
This means that on top of having a maintainable architecture, you also save time be being able to re-use modules you created for other projects.
Convinced ? Check out the Laravel-modules package and give it a try.