Laravel Modular Monolith: Bounded Contexts Guide | Mohamed Said [ ![Mohamed Said](https://cdn.msaied.com/01KT78WE565VEMM3PSNQAAB0MH.png) Mohamed Said Laravel Backend Engineer ](https://msaied.com) [ Home ](https://msaied.com) [ Projects ](https://msaied.com/projects) [ Articles ](https://msaied.com/articles) [ Certificates ](https://msaied.com/certificates) [ Contact ](https://msaied.com#contact-section) [ ](https://github.com/EG-Mohamed) [ Home ](https://msaied.com) [ Projects ](https://msaied.com/projects) [ Articles ](https://msaied.com/articles) [ Certificates ](https://msaied.com/certificates) [ Contact ](https://msaied.com#contact-section) [ home ](https://msaied.com) [ articles ](https://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. [ Internal Contracts: The Boundary Enforcement Mechanism ](#internal-contracts-the-boundary-enforcement-mechanism) 4. [ Enforcing Boundaries with Pest Architecture Tests ](#enforcing-boundaries-with-pest-architecture-tests) 5. [ Cross-Context Communication: Events Over Direct Calls ](#cross-context-communication-events-over-direct-calls) 6. [ Shared Kernel: What Belongs There ](#shared-kernel-what-belongs-there) 7. [ Takeaways ](#takeaways) ![Modular Monolith in Laravel: Enforcing Bounded Contexts Without a Microservices Tax](https://cdn.msaied.com/255/faefea356ccbfcca5cf942d369a35a6f.png) #laravel #architecture #ddd #modular-monolith Modular Monolith in Laravel: Enforcing Bounded Contexts Without a Microservices Tax ===================================================================================== 21 Jun 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 Internal Contracts: The Boundary Enforcement Mechanism ](#internal-contracts-the-boundary-enforcement-mechanism) 4. [ 04 Enforcing Boundaries with Pest Architecture Tests ](#enforcing-boundaries-with-pest-architecture-tests) 5. [ 05 Cross-Context Communication: Events Over Direct Calls ](#cross-context-communication-events-over-direct-calls) 6. [ 06 Shared Kernel: What Belongs There ](#shared-kernel-what-belongs-there) 7. [ 07 Takeaways ](#takeaways) Why a Modular Monolith? ----------------------- Microservices solve organisational scale problems. Most teams have a codebase problem: everything is tangled in `app/` with no enforced boundaries. A modular monolith gives you the conceptual separation of services — clear ownership, explicit contracts, independent testability — while keeping a single deployable unit and a shared database transaction. The goal is not folder aesthetics. It is **making illegal dependencies impossible to write** and legal ones obvious to read. --- Directory Layout ---------------- Drop the default `app/` catch-all and introduce a `src/` root with one directory per bounded context: ```php src/ Billing/ BillingServiceProvider.php Application/ # use-cases, commands, queries Domain/ # entities, value objects, domain events Infrastructure/ # Eloquent models, repositories, payment gateways UI/ # controllers, Filament resources, API resources Catalog/ ... Identity/ ... ``` Register `src/` in `composer.json`: ```json "autoload": { "psr-4": { "App\\": "app/", "Billing\\": "src/Billing/", "Catalog\\": "src/Catalog/", "Identity\\": "src/Identity/" } } ``` Each context owns a `ServiceProvider` that registers its own bindings, routes, and migrations. Boot them in `config/app.php` or via package auto-discovery if you extract them later. --- Internal Contracts: The Boundary Enforcement Mechanism ------------------------------------------------------ Contexts must never reach into each other's `Domain/` or `Infrastructure/` layers directly. Instead, expose a thin **facade interface** at the context root: ```php // src/Billing/BillingContext.php namespace Billing; interface BillingContext { public function chargeSubscription(SubscriptionId $id, Money $amount): ChargeResult; public function findInvoice(InvoiceId $id): ?InvoiceDto; } ``` The concrete implementation lives in `Billing\Infrastructure\LaravelBillingContext` and is bound in `BillingServiceProvider`: ```php $this->app->bind(BillingContext::class, LaravelBillingContext::class); ``` The `Catalog` context injects `BillingContext`, never an Eloquent model from `Billing\Infrastructure\Models\Invoice`. This is the contract. Violating it is a code-review failure, not a runtime error — unless you add architecture tests. --- Enforcing Boundaries with Pest Architecture Tests ------------------------------------------------- Pest's `arch()` helper lets you codify rules that CI enforces on every push: ```php // tests/Architecture/BoundaryTest.php arch('Catalog does not depend on Billing internals') ->expect('Catalog') ->not->toUse('Billing\\Domain') ->not->toUse('Billing\\Infrastructure'); arch('Domain layer stays pure') ->expect('Billing\\Domain') ->not->toUse('Illuminate\\Database') ->not->toUse('Illuminate\\Http'); arch('Infrastructure may use Eloquent') ->expect('Billing\\Infrastructure') ->toUse('Illuminate\\Database\\Eloquent\\Model'); ``` These tests run in milliseconds and catch the "quick fix" that imports an Eloquent model across a boundary. --- Cross-Context Communication: Events Over Direct Calls ----------------------------------------------------- When `Billing` needs to notify `Catalog` that a subscription expired, it dispatches a domain event. `Catalog` listens — but the listener is registered in `Catalog`'s own service provider: ```php // In CatalogServiceProvider Event::listen( \Billing\Domain\Events\SubscriptionExpired::class, \Catalog\Application\Listeners\SuspendCatalogListings::class, ); ``` `Billing` has no knowledge of `Catalog`. The event class lives in `Billing\Domain\Events` and is the only thing `Catalog` imports from `Billing` — and only the event DTO, never infrastructure. --- Shared Kernel: What Belongs There --------------------------------- Some concepts are genuinely cross-cutting: `Money`, `UserId`, `Pagination`, base `DomainEvent`. Place these in a `SharedKernel/` namespace: ``` src/ SharedKernel/ ValueObjects/ Money.php UserId.php Contracts/ DomainEvent.php ``` All contexts may depend on `SharedKernel`. No context may depend on another context's internals. This rule is simple enough to enforce in a team of ten. --- Takeaways --------- - **Folder structure alone is not architecture** — contracts and architecture tests are what enforce boundaries. - Each bounded context exposes one interface; callers depend on that interface, never on internal models. - Pest `arch()` tests are cheap to write and eliminate boundary drift in CI. - Domain events decouple contexts at runtime without a message broker. - A `SharedKernel` for genuine cross-cutting value objects prevents duplication without creating coupling. - You can extract any context to a microservice later because the contract already exists. Found this useful? [ ](https://twitter.com/intent/tweet?url=https%3A%2F%2Fmsaied.com%2Farticles%2Fmodular-monolith-in-laravel-enforcing-bounded-contexts-without-a-microservices-tax&text=Modular+Monolith+in+Laravel%3A+Enforcing+Bounded+Contexts+Without+a+Microservices+Tax) [ ](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fmsaied.com%2Farticles%2Fmodular-monolith-in-laravel-enforcing-bounded-contexts-without-a-microservices-tax) Frequently Asked Questions ---------------------------- 3 questions Q01 Should each bounded context have its own database schema or tables? In a modular monolith you typically share one database, but prefix tables per context (e.g. `billing_invoices`, `catalog_products`). Each context's Eloquent models and migrations live inside that context. This makes future extraction to separate databases straightforward without requiring a schema split on day one. Q02 How do you handle shared Eloquent models like User that multiple contexts need? The `User` model belongs to the `Identity` context. Other contexts receive a `UserId` value object and call `Identity\IdentityContext::findUser(UserId)` when they need user data. They never import `Identity\Infrastructure\Models\User` directly. This keeps the boundary clean while still allowing cross-context user lookups. Q03 Can this structure work with Filament admin panels? Yes. Each context's `UI/` layer can contain its own Filament resources and panels. Register them inside the context's service provider using Filament's `Panel::make()` or by calling `FilamentFacade::serving()`. The panel for `Billing` only registers resources from `Billing\UI\Filament`, never from other contexts. Continue reading More Articles --------------- [ View all ](https://msaied.com/articles) [ ![Laravel AI SDK: Tool-Calling Agents and Conversation Persistence](https://cdn.msaied.com/260/8c84f424e42da01993c9ba4b8eb19655.png) laravel ai agents ### Laravel AI SDK: Tool-Calling Agents and Conversation Persistence Build reliable tool-calling AI agents in Laravel using the Prism package. Learn how to wire tools, persist con... ![Mohamed Said](https://cdn.msaied.com/01KT78WE565VEMM3PSNQAAB0MJ.jpg) Mohamed Said 21 Jun 2026 3 min read Read ](https://msaied.com/articles/laravel-ai-sdk-tool-calling-agents-and-conversation-persistence) [ ![Laravel Livewire v3 Internals: Morph Markers, JS Hooks, and Alpine Integration](https://cdn.msaied.com/259/e8ce445f021c2b26ebe4dd5da50014f8.png) livewire laravel alpine ### Laravel Livewire v3 Internals: Morph Markers, JS Hooks, and Alpine Integration Go beyond the docs: understand how Livewire v3 diffs the DOM with morph markers, intercept the lifecycle with... ![Mohamed Said](https://cdn.msaied.com/01KT78WE565VEMM3PSNQAAB0MJ.jpg) Mohamed Said 21 Jun 2026 3 min read Read ](https://msaied.com/articles/laravel-livewire-v3-internals-morph-markers-js-hooks-and-alpine-integration) [ ![Laravel Package Development: Service Providers, Auto-Discovery, and Config Merging](https://cdn.msaied.com/258/673a80fa8e42ae375a4bba21bdcd92ea.png) laravel packages service-providers ### Laravel Package Development: Service Providers, Auto-Discovery, and Config Merging Build a production-ready Laravel package from scratch — covering service provider design, auto-discovery via c... ![Mohamed Said](https://cdn.msaied.com/01KT78WE565VEMM3PSNQAAB0MJ.jpg) Mohamed Said 21 Jun 2026 3 min read Read ](https://msaied.com/articles/laravel-package-development-service-providers-auto-discovery-and-config-merging-1) [ ![Mohamed Said](https://cdn.msaied.com/01KT78WE565VEMM3PSNQAAB0MH.png) Mohamed Said Laravel Backend Engineer ](https://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://msaied.com) - [Projects](https://msaied.com/projects) - [Articles](https://msaied.com/articles) - [Certificates](https://msaied.com/certificates) - [Contact](https://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)