Laravel Modular Monolith: Bounded Contexts Guide | Mohamed Said [ ![Mohamed Said](https://cdn.msaied.com/01KT78WE565VEMM3PSNQAAB0MH.png) Mohamed Said Laravel Backend Engineer ](https://www.msaied.com) [ Home ](https://www.msaied.com) [ Projects ](https://www.msaied.com/projects) [ Articles ](https://www.msaied.com/articles) [ Certificates ](https://www.msaied.com/certificates) [ Contact ](https://www.msaied.com#contact-section) [ ](https://github.com/EG-Mohamed) [ Home ](https://www.msaied.com) [ Projects ](https://www.msaied.com/projects) [ Articles ](https://www.msaied.com/articles) [ Certificates ](https://www.msaied.com/certificates) [ Contact ](https://www.msaied.com#contact-section) [ home ](https://www.msaied.com) [ articles ](https://www.msaied.com/articles) Modular Monolith in Laravel: Enforcing Bounded Contexts Without a Microservices Tax On this page 1. [ Why a Modular Monolith? ](#why-a-modular-monolith) 2. [ Directory Layout ](#directory-layout) 3. [ Registering Modules Automatically ](#registering-modules-automatically) 4. [ Defining a Public Contract ](#defining-a-public-contract) 5. [ Preventing Accidental Coupling with Pest Architecture Tests ](#preventing-accidental-coupling-with-pest-architecture-tests) 6. [ Cross-Module Communication via Events ](#cross-module-communication-via-events) 7. [ Database Boundaries ](#database-boundaries) 8. [ Takeaways ](#takeaways) ![Modular Monolith in Laravel: Enforcing Bounded Contexts Without a Microservices Tax](https://cdn.msaied.com/451/014ea4597c12e3ba1ce7a4f4a33d299e.png) #laravel #architecture #ddd #modular-monolith Modular Monolith in Laravel: Enforcing Bounded Contexts Without a Microservices Tax ===================================================================================== 21 Jul 2026 3 min read ![Mohamed Said](https://cdn.msaied.com/01KT78WE565VEMM3PSNQAAB0MJ.jpg) Mohamed Said Table of contents 1. [ 01 Why a Modular Monolith? ](#why-a-modular-monolith) 2. [ 02 Directory Layout ](#directory-layout) 3. [ 03 Registering Modules Automatically ](#registering-modules-automatically) 4. [ 04 Defining a Public Contract ](#defining-a-public-contract) 5. [ 05 Preventing Accidental Coupling with Pest Architecture Tests ](#preventing-accidental-coupling-with-pest-architecture-tests) 6. [ 06 Cross-Module Communication via Events ](#cross-module-communication-via-events) 7. [ 07 Database Boundaries ](#database-boundaries) 8. [ 08 Takeaways ](#takeaways) Why a Modular Monolith? ----------------------- Microservices solve distribution problems you probably don't have yet. A modular monolith gives you the domain isolation of microservices while keeping a single deployment unit, a shared database transaction, and zero network overhead between modules. The trick is enforcing the boundaries so the monolith never becomes a big ball of mud. Directory Layout ---------------- Organise by bounded context, not by technical layer: ```php app/ Modules/ Billing/ Actions/ Data/ # DTOs, value objects Events/ Http/ Models/ Providers/ Contracts/ # public interface for other modules Inventory/ ... Shared/ ... ``` Each module owns its own `ServiceProvider`. The `Shared` module holds cross-cutting concerns (money value objects, pagination DTOs, etc.) that every module may import. Nothing outside `Contracts/` is a stable API. Registering Modules Automatically --------------------------------- Add a `ModuleServiceProvider` that discovers and boots every module: ```php // app/Providers/ModuleServiceProvider.php class ModuleServiceProvider extends ServiceProvider { public function register(): void { foreach (glob(app_path('Modules/*/Providers/*ServiceProvider.php')) as $file) { $class = $this->classFromPath($file); $this->app->register($class); } } private function classFromPath(string $path): string { return str_replace( [app_path() . '/', '/', '.php'], ['App/', '\\', ''], $path ); } } ``` Register `ModuleServiceProvider` in `bootstrap/providers.php` (Laravel 11+) and every new module is picked up without touching any central file. Defining a Public Contract -------------------------- A module exposes only what other modules need: ```php // app/Modules/Billing/Contracts/BillingService.php interface BillingService { public function charge(CustomerId $customer, Money $amount): Receipt; public function currentPlan(CustomerId $customer): Plan; } ``` The concrete implementation lives inside `Billing` and is bound in `BillingServiceProvider`: ```php $this->app->bind(BillingService::class, StripeBillingService::class); ``` The `Inventory` module injects `BillingService`, never `StripeBillingService`. This is the boundary. Preventing Accidental Coupling with Pest Architecture Tests ----------------------------------------------------------- Pest's `arch()` helper lets you codify boundaries as executable tests: ```php // tests/Architecture/ModuleBoundariesTest.php arch('Inventory does not reach into Billing internals') ->expect('App\Modules\Inventory') ->not->toUse('App\Modules\Billing\Actions') ->not->toUse('App\Modules\Billing\Models'); arch('Billing only exposes its Contracts namespace') ->expect('App\Modules\Billing\Actions') ->not->toBeUsedIn('App\Modules\Inventory'); arch('Shared module has no module-specific imports') ->expect('App\Modules\Shared') ->not->toUse('App\Modules\Billing') ->not->toUse('App\Modules\Inventory'); ``` These tests run in milliseconds and fail the CI pipeline the moment a developer reaches across a boundary. Cross-Module Communication via Events ------------------------------------- When `Billing` needs to tell `Inventory` that a subscription was cancelled, it dispatches a domain event rather than calling an `Inventory` class directly: ```php // Billing dispatches: event(new SubscriptionCancelled($customerId, $plan, now())); // Inventory listens: class FreezeInventoryAllotment { public function handle(SubscriptionCancelled $event): void { // Inventory-specific logic only } } ``` The event lives in `Billing\Events` (the source of truth). `Inventory` depends on the event class — that's acceptable because events are part of the public contract surface. Database Boundaries ------------------- You share one database, but each module should prefix its tables (`billing_invoices`, `inventory_products`). Avoid cross-module Eloquent relationships; use IDs and re-query inside the target module. This keeps migrations independent and makes a future extraction to a separate service mechanical rather than surgical. Takeaways --------- - Organise by bounded context; let each module own its `ServiceProvider`. - Expose only `Contracts/` interfaces — never concrete classes or internal models. - Use Pest `arch()` tests to make boundary violations a CI failure, not a code-review debate. - Communicate across modules with domain events, not direct method calls. - Prefix tables per module so schema ownership is unambiguous. - A modular monolith is the right default; extract to microservices only when you have a proven scaling or team-autonomy reason. Found this useful? [ ](https://twitter.com/intent/tweet?url=https%3A%2F%2Fwww.msaied.com%2Farticles%2Fmodular-monolith-in-laravel-enforcing-bounded-contexts-without-a-microservices-tax-3&text=Modular+Monolith+in+Laravel%3A+Enforcing+Bounded+Contexts+Without+a+Microservices+Tax) [ ](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fwww.msaied.com%2Farticles%2Fmodular-monolith-in-laravel-enforcing-bounded-contexts-without-a-microservices-tax-3) Frequently Asked Questions ---------------------------- 3 questions Q01 Can modules share an Eloquent model, for example a shared User? Avoid it. Instead, each module that needs user data should define a thin read model or query its own projection. If a shared User is unavoidable, place it in the Shared module and treat it as a stable, rarely-changing contract. Q02 How do Pest architecture tests differ from PHPStan for enforcing boundaries? PHPStan catches type errors and undefined references. Pest arch() tests express intentional architectural rules — 'this namespace must not use that namespace' — which PHPStan has no concept of. Both tools are complementary; use PHPStan for type safety and Pest arch() for boundary enforcement. Q03 When should I actually split a module into a separate service? When a module has a genuinely different scaling profile, needs independent deployment cadence, or a separate team owns it end-to-end. Organisational and operational reasons justify the distribution tax; technical complexity alone rarely does. Continue reading More Articles --------------- [ View all ](https://www.msaied.com/articles) [ ![DDD Value Objects and DTOs in Laravel Without the Bloat](https://cdn.msaied.com/450/41688537085b86f102fd8c219a35319f.png) laravel ddd php ### DDD Value Objects and DTOs in Laravel Without the Bloat Learn how to implement domain-driven value objects and data transfer objects in Laravel using PHP 8.3 readonly... ![Mohamed Said](https://cdn.msaied.com/01KT78WE565VEMM3PSNQAAB0MJ.jpg) Mohamed Said 21 Jul 2026 1 min read Read ](https://www.msaied.com/articles/ddd-value-objects-and-dtos-in-laravel-without-the-bloat) [ ![Laravel + Python FastAPI: Image OCR Demo](https://cdn.msaied.com/447/5f3d87146fbf19957973cbc88c6c0155.png) Laravel Python FastAPI ### Laravel + Python FastAPI: Image OCR Demo Learn how to call a Python image OCR script from Laravel using FastAPI as the bridge. This premium tutorial wa... ![Mohamed Said](https://cdn.msaied.com/01KT78WE565VEMM3PSNQAAB0MJ.jpg) Mohamed Said 20 Jul 2026 3 min read Read ](https://www.msaied.com/articles/laravel-python-fastapi-image-ocr-demo) [ ![Laravel SMS Catcher: A Local Dashboard for SMS Notifications](https://cdn.msaied.com/452/6cf05170f76a3b6c340dda18ee3bbc62.png) Laravel SMS Local Development ### Laravel SMS Catcher: A Local Dashboard for SMS Notifications Laravel SMS Catcher is a local development package that intercepts outgoing SMS notifications and displays the... ![Mohamed Said](https://cdn.msaied.com/01KT78WE565VEMM3PSNQAAB0MJ.jpg) Mohamed Said 20 Jul 2026 3 min read Read ](https://www.msaied.com/articles/laravel-sms-catcher-a-local-dashboard-for-sms-notifications) [ ![Mohamed Said](https://cdn.msaied.com/01KT78WE565VEMM3PSNQAAB0MH.png) Mohamed Said Laravel Backend Engineer ](https://www.msaied.com)Senior Backend Engineer specializing in Laravel, scalable SaaS platforms, APIs, and cloud infrastructure. I build secure, high-performance web applications that help businesses grow. Explore - [Home](https://www.msaied.com) - [Projects](https://www.msaied.com/projects) - [Articles](https://www.msaied.com/articles) - [Certificates](https://www.msaied.com/certificates) - [Contact](https://www.msaied.com#contact-section) Connect - [ hello@msaied.com ](mailto:hello@msaied.com) - [ +20 109 461 9204 ](tel:+201094619204) © 2026 Mohamed Said. All rights reserved. [ ](https://github.com/EG-Mohamed) [ ](https://www.linkedin.com/in/msaiedm/) [ ](https://wa.me/201094619204) [ ](mailto:hello@msaied.com) [ ](https://drive.google.com/file/u/0/d/1MF20IPRJyzfy32mhEutjL5EpSls0w2Q8/view)