Weave Code
Weaver
Helps Laravel developers discover, compare, and choose open-source packages. See popularity, security, maintainers, and scores at a glance to make better decisions.
Feedback
Share your thoughts, report bugs, or suggest improvements.
Subject
Message
Modular Monolith Bundle

Modular Monolith Bundle Laravel Package

landingi/modular-monolith-bundle

A Symfony bundle from Landingi for building modular monolith applications, offering structure and tooling to organize code into modules while keeping a single deployable unit. Helps teams enforce boundaries and scale development without microservices overhead.

View on GitHub
Deep Wiki
Context7

landingi/modular-monolith-bundle helps you organize a Laravel application as a modular monolith—keeping a single deployable codebase while separating concerns into explicit, self-contained modules. Each module owns its own domain logic, service providers, and boundaries, so teams get the clarity of a modular architecture without adopting the operational overhead of distributed services.

The bundle focuses on predictable structure and convention, making it easier to onboard contributors and evolve the codebase as it grows.

  • Explicit module boundaries with conventional directory layout
  • Service provider registration per module
  • Clear separation of domain, application, and infrastructure concerns
  • Composable structure that scales without microservices
  • Lightweight, Laravel-native integration
Frequently asked questions about Modular Monolith Bundle
Can I install landingi/modular-monolith-bundle in a Laravel application?
No. Despite often being described as a Laravel/PHP package, landingi/modular-monolith-bundle is a Symfony bundle: it is registered through bundles.php and hooks into the Symfony container and compiler-pass lifecycle. A Laravel application cannot install or boot it. Laravel teams can only read it as a reference for modular monolith pattern ideas.
What Symfony and PHP versions does landingi/modular-monolith-bundle support?
The package has a single release dated 2021-05-18, so assume a Symfony 4.4/5.x and PHP 7.4/8.0 vintage until proven otherwise. Check the composer.json constraints for symfony/* and php before planning anything. There is no visible PHP 8.2/8.3 or Symfony 6/7 compatibility work. On a modern Symfony 6.4/7.x platform, treat it as non-installable without a fork.
How do I install landingi/modular-monolith-bundle with Composer?
Installation is only relevant for Symfony applications: require the package with Composer and register the bundle in bundles.php. There is no Laravel service provider or package discovery support. Because the package is stale and has zero dependents, spike it in a throwaway Symfony app first and confirm the version matrix before adding it to a real deployment path.
Is landingi/modular-monolith-bundle maintained and safe for production?
The signals are poor: zero stars, zero dependents, one release in 2021, and no visible community or maintainer activity. It has been unmaintained for roughly four years, with no security response path and no deprecation fixes. Because bundles that own compiler passes and service wiring can break loudly at build time, a failed cache clear could block every deploy. Direct dependency in production is not recommended.
What does a modular monolith bundle actually do for module boundaries?
The concept is sound: organize application code into self-contained modules inside a single deployable codebase, with conventions for module registration, service wiring, and an internal contract or event layer between modules. The real value is codifying boundaries so they do not erode under delivery pressure, without taking on distributed-system complexity. What this specific bundle implements beyond structure and conventions needs verification in the source.
Does landingi/modular-monolith-bundle enforce module boundaries or just suggest them?
This is the key unknown. The available context does not document whether the bundle fails the build on a forbidden cross-module reference or merely encourages boundaries through conventions and autowiring. Inspect the compiler passes and module registry to find out. If it actively enforces boundaries, the value proposition is much stronger; if it only suggests them, it is mostly a naming convention.
How are cross-module dependencies handled in landingi/modular-monolith-bundle?
The repository does not document this clearly. Possible approaches include synchronous service injection, an in-process command/query bus, or domain events between modules. Read the module descriptor format and service wiring code before assuming decoupling. The choice matters because synchronous injection creates runtime coupling even when directories look separate.
Is landingi/modular-monolith-bundle coupled to Doctrine or a specific directory structure?
Expect conventions tuned to Landingi's own layout and naming, and possible coupling to Doctrine or an internal module descriptor format. The package appears to be an internal extraction published for convenience rather than a supported open-source product. Verify composer.json and source for hard dependencies before evaluating portability. This coupling is a major reason to adopt the pattern rather than the code.
Can I generate a module dependency diagram or CI check from landingi/modular-monolith-bundle?
There is no evidence that the bundle exposes an introspectable module graph. If its compiler passes already validate cross-module references, a CI check might be derivable, but that is not documented. For a Laravel codebase, build an in-house module registry plus a static-analysis check using tools such as Deptrac or PHPArkitect instead. That gives you a dependency diagram and CI enforcement on your own terms.
What are alternatives to landingi/modular-monolith-bundle for Laravel modular monoliths?
Laravel has no direct equivalent, so pattern adoption is the pragmatic route. Use nwidart/laravel-modules for module structure if it fits your conventions, and add in-house boundary checks or Deptrac/PHPArkitect rules for dependency enforcement. The recommended approach is to extract the module-descriptor idea and implement a small registry plus boundary validation yourself. Forking the Symfony bundle is only viable if a spike shows it does something non-trivial you cannot reproduce.
Weaver

How can I help you explore Laravel packages today?

Conversation history is not saved when not logged in.
Prompt
Add packages to context
No packages found.
store-doc/laravel-storage-driver
plus-it/laravel-translation-manager
diephp/perhaps
diephp/telegraph
osmaviation/spreadsheet
microsoft/fluentui-system-icons
mmccook/php-json-canonicalization-scheme
middlewares/firewall
qubiqx/montapacking
nyoncode/laravel-package-console
pnscripts/filament-broadquill-lite
pnscripts/laravel-sentfold-lite
vleap/mx-sdk-laravel-internal
twidpay/utils
htetmyathlaing/scout-elasticsearch-driver
artisan-toolbox/front-awesome
ls/client-assistant
users-au/laravel-client
cgv/localized-resource
noith/settings