Modular Laravel App

What is a Modular Laravel App?

Instead of keeping everything inside the default app/ folder (Controllers, Models, Views, etc.), you split your project into independent feature-based modules.

Each module behaves almost like a mini-Laravel app, with its own controllers, models, views, routes, configs, migrations, etc.

How It Works (Flow)

1 Application Bootstraps (index.php -> Kernel)

• Laravel strats normally (pubic/index.php) -> loads service providers, configs, routes, etc.).
• The modular package (e.g., nwidart/laravel-modules) registers a ModuleServiceProvider.

2 Module Registration

• Each module is discovered via module_statuses.json or config.
• Active modules get bootstrapped by the framework.

3 Routing per Module

• Each module can define its own Routes/web.php and Routes/api.php.
• When a request comes in:
  • Laravel checks routes normally.
  • If it matches a module's route -> that module's controller is invoked.

4 Module's Controller & Business Logic

• Inside the module, you have Http/Controller/SomeController.php.
• It calls services, models, or repositories defined within that same module.

5 Database / Models per Module

• Modules can define their own Entities (Models) and Migrations.
• Migrations are loaded when you run php artisan module:migrate ModuleName.

6 View & Assets per Module

• Each module has its own Resources/views and Resources/assets/

• You can load them with:

  return view('Blog::posts.index');
  

  (where Blog is the module name).

7 Service Providers per Module

• Each module can have a Providers/ModuleServiceProvider.php.
• This lets it:
  • Register bindings in the container
  • Load configs
  • Publish assets
  • Hook into Laravel's lifecycle

8 Inter-Module Communication

• Ideally, modules are loosely coupled.
• Communication happens via:
  • Events (Event::dispatch)
  • Intefaces & dependency injection
  • Service container bindings

Example Structure (with nwidart/laravel-modules)

app/
bootstrap/
config/
Modules/
   Blog/
      Config/
      Database/
         Migrations/
         Seeders/
      Http/
         Controllers/
         Middleware/
      Models/
      Providers/
      Resources/
         views/
         lang/
      Routes/
         web.php
         api.php
      module.json
   User/
      (similar structure)
public/
routes/

Benefits:

• Separation of concerns -> each feature lives independently.
• Reusability -> modules can be reused across projects.
• Team collaboration -> multiple teams can work on different modules without conflicts.
• Scalability -> easier to maintain large applications.

Real Life Analogy

Think of your Laravel app as a shopping mall.

• Laravel Core (Mall Infrastructure)
  • The mall's electricity, security, parking, elevators, etc. (basic services).
  • In Laravel, this is the framework itself (routing, middleware, service container, etc.).
• Modules (Individual Shops in the Mall)
  • Each shop is independent (Clothing store, Food court, Cinema).
  • In Laravel, each modules is like a mini-app:
    • Has its own routes (entry door)
    • Has its own controllers (shop staff)
    • Has its own models (shop inventory)
    • Has its own views (shop layout & display)
• Customers (User)
  • A customer enters the mall and chooses which shop to visit.
  • In Laravel, the HTTP request URL decides which module to route to.
• Mall Manager (Kernel + Module Loader)
  • Ensures shops follow the rules, stay open/closed, and work together.
  • In Laravel, the Kernel & Service Providers load and manage modules.

Example:

• Request: https://example.com/blog/posts
  • Mall analogy -> Customer goes to the Bookshop.
  • Laravel analogy -> The request hits the Blog Module, handled by PostController.
• Request: https://example.com/user/profile
  • Mall analogy -> Customer goes to the salon.
  • Laravel analogy -> The request hits the User Module, handled by ProfileController.