https://github.com/KalimeroMK/modular-laravel-boilerplate
This Laravel boilerplate provides a modular structure that allows for easy creation, organization, and management of modules within Laravel applications. Instead of using a monolithic approach, this architecture ensures that each module is an independent unit with its own controllers, models, repositories, and services.
By adopting this structure, developers can maintain cleaner and more scalable projects, reducing code duplication and making feature expansions more manageable.
Why Choose a Modular Approach?
Advantages
• Improved Code Organization – Each module acts as an isolated unit, making it easier to navigate through the codebase.
• Reusable Code – Modules can be repurposed across different projects with minimal changes.
• Scalability – Adding new features is straightforward without affecting existing functionality.
• Encapsulation – Prevents unnecessary dependencies between different parts of the application.
• Better Team Collaboration – Developers can work independently on separate modules without interfering with each other's work.
Disadvantages
• Higher Complexity – Beginners might struggle with understanding modular architecture.
• Increased File Count – Each module introduces additional files, potentially making the project look bulkier.
• Additional Configuration – Requires setup of stub files for automated code generation.
How to Use This Boilerplate?
1. Generating a New Module
You can create a new module using the following command:
php artisan make:module Blog
2. Adding API Support to a Module
If API support is required, use the `--api` flag:
php artisan make:module Blog --api
3. Module Structure
Once a module is created, its structure will be as follows:
app/Modules/{ModuleName}
│── Config/
│── database/
│ ├── migrations/
│ ├── factories/
│ ├── seeds/
│── Exeptions (if --api flag is used)
│── Helpers/
│── Http/
│ ├── Controllers/
│ │ ├── {ModuleName}Controller.php
│ │ ├── Api/{ModuleName}Controller.php (if --api flag is used)
│ ├── Requests/
│ ├── Resources/
│── Interfaces/{ModuleName}Interface.php
│── Models/{ModuleName}.php
│── Repositories/{ModuleName}Repository.php
│── Resource
│ ├── Land
│ ├── Views
│── routes
│ ├── api.php (if --api flag is used)
│ ├── web.php
│── Services/{ModuleName}Service.php
│── Traits
└──
Stub Files and Their Role
Stub files are predefined templates used for automated code generation, significantly speeding up development. Here are some of the key stub files used:
• Controllers: stubs/module/Http/Controllers/Controller.stub
• API Controllers: stubs/module/Http/Controllers/ApiController.stub
• Resources: stubs/module/Http/Resource/Resource.stub
• Models: stubs/module/Model.stub
• Repositories: stubs/module/Repository.stub
• Services: stubs/module/Service.stub
• Routes: stubs/module/routes/api.stub and stubs/module/routes/web.stub
Conclusion
This modular approach in Laravel offers enhanced organization, maintainability, and efficient project scaling. Although it requires additional setup and has a learning curve, the long-term benefits outweigh these initial hurdles. Stub files play a crucial role in automating code generation, making this architecture both effective and productive.
However, it's important to note that multiple Laravel packages exist to facilitate modular development. Some popular choices include:
• Nwidart/Modules – A well-maintained package providing full modular support in Laravel.
• Laravel-modules by Caffeinated – Another package offering an easy way to organize Laravel applications into modules.
• Laravel-boilerplate – A more opinionated boilerplate that integrates multiple pre-configured features.
Pros and Cons of Using Pre-Built Packages
Pros
• Faster setup – Avoids manual configuration and allows developers to start immediately.
• Community Support – Actively maintained with extensive documentation and community contributions.
• Standardized Best Practices – Ensures compatibility with widely adopted coding standards.
Cons
• Less Flexibility – Pre-built packages impose predefined structures that may not always fit specific project needs.
• Additional Dependencies – Adds third-party dependencies that may require future maintenance.
• Learning Curve – Requires understanding the package-specific configurations and limitations.
https://github.com/KalimeroMK/modular-laravel-boilerplate