Laravel Modular Monolith: Bounded Contexts Guide | Mohamed Said [Skip to content](#main) [ ![](https://cdn.msaied.com/01KT78WE565VEMM3PSNQAAB0MH.png) Mohamed SaidLaravel Backend Engineer ](https://www.msaied.com/public) - [Home](https://www.msaied.com/public) - [Projects](https://www.msaied.com/public/projects) - [Articles](https://www.msaied.com/public/articles) - [Certificates](https://www.msaied.com/public/certificates) - [About](https://www.msaied.com/public#about) [ Contact](https://www.msaied.com/public#contact) Menu Menu ---- Close - [HomeStart here](https://www.msaied.com/public) - [ProjectsCase studies](https://www.msaied.com/public/projects) - [ArticlesEngineering notes](https://www.msaied.com/public/articles) - [CertificatesCredentials](https://www.msaied.com/public/certificates) - [AboutHow I work](https://www.msaied.com/public#about) - [ContactGet in touch](https://www.msaied.com/public#contact) [Start a conversation](https://www.msaied.com/public#contact) [WhatsApp](https://wa.me/201094619204) [Email](mailto:hello@msaied.com) 1. [Home](https://www.msaied.com/public) 2. / 3. [Articles](https://www.msaied.com/public/articles) 4. / 5. Modular Monolith in Laravel: Enforcing Bounded Contexts Without a Microservices Tax Modular Monolith in Laravel: Enforcing Bounded Contexts Without a Microservices Tax ==================================================================================== Learn how to carve a Laravel application into cohesive bounded contexts using modules, internal contracts, and automated architecture tests — without splitting into microservices. ![](https://cdn.msaied.com/01M22N44A70A5MC2S599JP0MPH.webp) [Mohamed Said](https://www.msaied.com/public#person) Published 21 Jun 2026 · Updated 21 Jun 2026 · 3 min read ShareCopy linkCopied ![Modular Monolith in Laravel: Enforcing Bounded Contexts Without a Microservices Tax](https://cdn.msaied.com/255/faefea356ccbfcca5cf942d369a35a6f.png) 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) 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. - [laravel](https://www.msaied.com/public/articles?search=laravel) - [architecture](https://www.msaied.com/public/articles?search=architecture) - [ddd](https://www.msaied.com/public/articles?search=ddd) - [modular-monolith](https://www.msaied.com/public/articles?search=modular-monolith) Frequently asked questions --------------------------- 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. 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. 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. ![Mohamed Said](https://cdn.msaied.com/01M22N44A70A5MC2S599JP0MPH.webp)About the author ---------------- [Mohamed Said](https://www.msaied.com/public#person)Senior Backend Engineer specializing in Laravel, scalable SaaS platforms, APIs, and cloud infrastructure. I build secure, high-performance web applications that help businesses grow. [About](https://www.msaied.com/public#about) [GitHub ↗](https://github.com/EG-Mohamed) [LinkedIn ↗](https://www.linkedin.com/in/msaiedm/) [WhatsApp ↗](https://wa.me/201094619204) [Email Address ↗](mailto:hello@msaied.com) [My CV ↗](https://drive.google.com/file/u/0/d/1MF20IPRJyzfy32mhEutjL5EpSls0w2Q8/view) [Previous articleEvent Sourcing in Laravel: Aggregates, Projectors, and Reactors Without the Framework Tax](https://www.msaied.com/public/articles/event-sourcing-in-laravel-aggregates-projectors-and-reactors-without-the-framework-tax-1) [Next articleDomain-Driven Design in Laravel: Actions, DTOs, and Value Objects Without Bloat](https://www.msaied.com/public/articles/domain-driven-design-in-laravel-actions-dtos-and-value-objects-without-bloat-2) 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) ### Have a technical challenge? Tell me what you’re building. I reply within two working days. [Start a conversation](https://www.msaied.com/public#contact) Related articles ----------------- [ ![](https://cdn.msaied.com/740/cce86edc21eddcbdd2f2454fadaf9c70.png) · 3 min read### The Pipeline Pattern in Laravel: Custom Pipelines Beyond Middleware 5 Oct 2026 ](https://www.msaied.com/public/articles/the-pipeline-pattern-in-laravel-custom-pipelines-beyond-middleware-1) [ ![](https://cdn.msaied.com/739/2d6897fdcdcf090613f96f72a64b8a78.png) · 4 min read### MySQL Full-Text Search in Laravel: Indexes, Relevance Scoring, and Boolean Mode 4 Oct 2026 ](https://www.msaied.com/public/articles/mysql-full-text-search-in-laravel-indexes-relevance-scoring-and-boolean-mode) [ ![](https://cdn.msaied.com/738/073696a3fefe18bec825beec5ac658f5.png) · 4 min read### Laravel Queue Rate-Limited Middleware: Throttling Jobs Without Losing Work 4 Oct 2026 ](https://www.msaied.com/public/articles/laravel-queue-rate-limited-middleware-throttling-jobs-without-losing-work) Have a technical challenge? ---------------------------- Tell me what you’re building. I reply within two working days. [Discuss your project ↗](https://www.msaied.com/public#contact) © 2026 Mohamed Said · Built with Laravel, meant to last.Senior Backend Engineer specializing in Laravel, scalable SaaS platforms, APIs, and cloud infrastructure. I build secure, high-performance web applications that help businesses grow. - [Home](https://www.msaied.com/public) - [Articles](https://www.msaied.com/public/articles) - [Certificates](https://www.msaied.com/public/certificates) - [GitHub](https://github.com/EG-Mohamed) - [LinkedIn](https://www.linkedin.com/in/msaiedm/) - [WhatsApp](https://wa.me/201094619204) - [Email Address](mailto:hello@msaied.com) - [My CV](https://drive.google.com/file/u/0/d/1MF20IPRJyzfy32mhEutjL5EpSls0w2Q8/view) - [Sitemap](https://www.msaied.com/public/sitemap.xml)