Modular Monolith Bundle Laravel Package

Technical Evaluation

Framing correction first: despite the brief describing this as a "Laravel/PHP package," landingi/modular-monolith-bundle is a Symfony bundle. It is registered via bundles.php and hooks into the Symfony container/compiler-pass lifecycle. A Laravel team cannot install it; at best they can read it as a reference for pattern ideas. This distinction should be resolved before any build/buy decision, because it eliminates the package for Laravel shops entirely.

Architecture fit: The underlying idea — a modular monolith with enforced module boundaries, an internal contract/event layer between modules, and container-level wiring — is a sound default for a mid-size SaaS where microservices would be premature but a single unstructured codebase is already hurting. The bundle's real value is in codifying boundaries (module registry, service wiring conventions, possibly compiler passes that validate cross-module dependencies) so they don't erode under delivery pressure. That is a pattern worth adopting almost regardless of vendor.

Integration feasibility: Low cost to spike, high cost to depend on. The package has 0 stars, 0 dependents, a single release dated 2021-05-18, and no visible community. It reads as an internal Landingi extraction published for convenience rather than a supported OSS product. Expect thin or absent documentation, conventions tuned to Landingi's own directory layout and naming, and probable coupling to Doctrine or their internal module descriptor format.

Technical risk:

• Unmaintained for ~4 years. No security response path, no PHP 8.2/8.3 or Symfony 6/7 compatibility work, no deprecation fixes.
• Container-level coupling is the highest-risk surface. Bundles that own compiler passes and service wiring break loudly and at build time when Symfony internals shift — a failed cache:clear blocks every deploy.
• Bus factor of effectively zero. No maintainer to escalate to.
• Unknown enforcement semantics. Does it enforce boundaries (fails the build on a violation) or merely encourage them (convention + autowiring)? This single answer changes the value proposition entirely.

Key questions to answer before committing:

1. What does the bundle actually do at compile time vs. runtime — registry only, or active boundary enforcement?
2. What are the composer.json constraints for symfony/* and php? Does it install on our target versions at all?
3. How are cross-module dependencies expressed — synchronous service injection, an in-process command/query bus, or domain events?
4. Is it coupled to Doctrine, a specific directory structure, or Landingi naming conventions?
5. Is the module graph introspectable (can we generate a dependency diagram / CI check from it)?
6. Is the license/attribution clean for a fork (MIT suggests yes — confirm headers)?

Integration Approach

Stack fit: Assume a Symfony 4.4/5.x and PHP 7.4/8.0 vintage until proven otherwise from composer.json and the 2021 release tag. If our platform is Symfony 6.4/7.x on PHP 8.2+, treat this as non-installable without a fork, and plan accordingly.

Migration path — three options, in descending order of preference:

1. Pattern adoption (recommended default). Treat the repo as a reference implementation. Extract the module-descriptor shape and boundary-checking approach, implement a minimal in-house equivalent (a module registry service plus one compiler pass that validates forbidden cross-module references). This is typically a few hundred lines and gives us ownership, docs, and version compatibility on our terms.
2. Fork and own. Vendor the code into a private VCS, pin it, and take on maintenance. Viable only if the spike shows the bundle does something non-trivial we'd struggle to reproduce (e.g., a mature inter-module message bus).
3. Direct dependency. Not recommended given adoption and staleness signals; a single-release, zero-dependent package in the deployment path is an unhedged operational bet.

Compatibility work required regardless of option: build a version matrix (bundle × Symfony × PHP), run composer why-not against our current lockfile, and check for deprecation noise under our PHP version. Budget for a composer.json constraint widening if we fork.

Sequencing:

1. Spike (1 week, one senior engineer): clone, read source, install into a throwaway Symfony skeleton, and answer the six questions above. Output: a one-page verdict on enforce-vs-encourage and modern-Symfony viability.
2. Boundary PoC (2–3 weeks): apply the pattern to one bounded context in the real codebase; prove that a deliberate cross-module violation fails CI.
3. Decision gate: adopt pattern, fork, or drop — decided on the PoC evidence, not on the package's stated intent.
4. Rollout: module-by-module, starting with the least-coupled context; do not attempt a big-bang restructure of the monolith.

Operational Impact

Maintenance: We become the maintainer in every scenario except "pattern only." No upstream commits since 2021 means no security patches, no Symfony compatibility updates, and no bug fixes. Any fork needs a named owner, a documented review cadence, and a plan to re-evaluate the fork's necessity annually.

Support: Effectively none. No maintainer, no docs, no dependents to consult, no Stack Overflow corpus. Onboarding cost is "read the source." Escalation path is internal only — this must be an explicit, accepted risk, not a discovered one.

Scaling: Runtime performance impact is negligible — this is an architectural/structural tool, not a throughput component. Its scaling value is organizational: it lets more teams commit to one deployable without stepping on each other, and it keeps the option of extracting a module into a service later without a rewrite. Frame the ROI in team-velocity terms, not infrastructure terms.

Failure modes to design against:

• Build-time breakage. Compiler passes failing on Symfony upgrade blocks all deploys. Mitigation: pin Symfony minor versions in the same PR that touches the bundle wiring; run container compilation in CI as a gated check.
• Silent boundary erosion. If enforcement is convention-only, boundaries decay within two quarters. Mitigation: verify the CI check actually fails on a seeded violation.
• Event bus as hidden coupling. In-process messaging between modules feels decoupled but can recreate a distributed monolith inside one process — hard to trace, hard to debug. Mitigation: require explicit, documented module contracts and keep the event surface small.
• Abandonment déjà vu. The most likely failure is that the fork itself goes stale. Mitigation: minimal-code philosophy and a documented "why we built this" doc so a future team can retire it.

Ramp-up: Expect 1–2 weeks for a senior Symfony engineer to fully map the API and constraints; add ~1 week per additional engineer for team-wide literacy. Budget for internal documentation as a first-class deliverable, since none exists upstream.

Bottom line: High-value pattern, low-value dependency. Recommend a one-week spike to harvest the architectural ideas, with a strong prior toward in-house implementation over adopting the package itself.