Architect Bundle Laravel Package

Product Decisions This Supports

• Framework fit — the decisive input. Despite being framed as a "Laravel/PHP package," this is a Symfony bundle (mb-x/architect-bundle) with no Laravel integration. For a Laravel roadmap the honest decision is: not adoptable, only conceptually portable. Any evaluation should be scoped as "Symfony-only."
• Build vs. buy on internal architecture conventions. The real decision this informs is whether to buy a layering opinion (install a bundle that dictates job/domain/application/infrastructure separation) or build one (a short ADR plus a skeleton repo and static-analysis rules). Given 7 stars, 0 dependents, and a 0.095 score, the "buy" side is weak — this is a pattern reference, not a dependency.
• Roadmap priority: deprioritize as a dependency, consider as a 1–2 day spike. It enables no end-user feature; it is an engineering-velocity and code-consistency investment. It should compete against other internal-debt items, not against product features.
• Use cases where the underlying idea earns a look:
  • Greenfield Symfony services where 5+ engineers are already bleeding business logic into controllers, entities, or repositories.
  • Pre-decomposition monoliths where you want layer boundaries visible before service extraction.
  • Onboarding consistency across squads — a structural convention that shortens architecture review cycles.
• Use cases it does not support: Laravel feature work, any team needing a supported dependency, and any team that has not first tried lightweight enforcement (Deptrac, PHPArkitect, PHPStan layers) — those deliver most of the value with none of the ownership risk.

When to Consider This Package

Consider it when:

• The stack is genuinely Symfony and will stay Symfony.
• You have layer-bleed pain you can name with evidence (fat controllers, cross-layer calls, untestable services), not a hypothetical.
• You are willing to vendor or fork it and assign an owner — bus factor is effectively 1, there is no security policy, no release cadence signal, and zero dependents means zero production battle-testing.
• Composer constraints check out against your Symfony LTS/current version — verify before any spike, since an unmaintained bundle pinned to an old major is a dead end.
• You treat the spike deliverable as an internal ADR + skeleton, with the bundle as one input rather than the output.

Look elsewhere when:

• The stack is Laravel. Use native service/action patterns, lorisleiva/laravel-actions, or modular packaging (nwidart/laravel-modules) — do not port a Symfony bundle's mechanics into a Laravel codebase.
• You need LTS guarantees, a CVE response path, or commercial support. A 7-star, 0-dependent package cannot meet that bar.
• You only need enforcement rather than a prescribed structure — static analysis rules are cheaper, framework-agnostic, and reversible.
• The team lacks appetite to own a fork. In that case the correct decision is to decline and write the convention down internally.

Default recommendation: adopt the idea, reject the dependency. Budget a short spike to extract the layering model into your own ADR and skeleton, and revisit only if the package gains maintainers, dependents, and a release history.

How to Pitch It (Stakeholders)

To executives: This is not a product feature and it will not move customer-facing metrics. It is an internal consistency play: a small, bounded bet that could shorten onboarding and reduce architecture review churn in a Symfony codebase. The costs are a short evaluation spike plus permanent ownership of a fork, because the package is a single-maintainer project with negligible community traction (7 stars, no dependents). Recommendation: borrow the pattern, not the dependency — capture the layering model in our own standards and skeleton, spend nothing on ongoing maintenance, and keep the option to revisit. This also clarifies a scoping error worth correcting early: the package is Symfony-only and does not apply to our Laravel work at all, so it should not appear on a Laravel roadmap.

To engineering: The value is a prescribed separation of job layers — clearer boundaries, less coupling, more testable services, and a shared vocabulary for reviews. The risk is that we inherit someone else's structure and someone else's maintenance burden. Proposed path: a 1–2 day spike comparing this bundle's model against Deptrac/PHPArkitect enforcement plus a hand-rolled skeleton, with the deliverable being an ADR and a starter template we own. Success looks like fewer layer-violation review comments and faster ramp-up on new services — measure that, not adoption of the package itself.