Bus Laravel Package

Product Decisions This Supports

• CQRS-lite adoption. The real decision isn't "should we install this package," it's "do we standardize one-action-per-handler in our Laravel codebase?" This package is the enforcement plumbing for that convention.
• Build vs. buy vs. adopt. The package is a thin dispatcher (~a few hundred LOC). The realistic options are: adopt it, vendor/fork it, or write an equivalent internal adapter. Framing it as a pattern decision rather than a dependency decision keeps the roadmap honest.
• Modular monolith / future service extraction. A command/query bus is the seam that lets a module later become a service without rewriting controllers. Relevant if the roadmap includes splitting modules or moving write paths to async workers.
• Feature work on complex write flows. Multi-step forms, wizard flows, admin back-office operations, and anything with side effects benefit from one handler per action, with middleware as a single choke point for transactions, validation, audit logging, and authorization.
• Third-party integration work. Each external call becomes a discrete, testable, retryable action instead of being buried in a controller.
• Engineering standards and onboarding. A documented bus convention reduces PR review variance and shortens time-to-first-useful-PR for new hires on a legacy Laravel app.
• Test strategy. Dispatching commands and asserting on handlers (no HTTP layer) is a direct lever on test-suite runtime and CI cost — worth measuring on a pilot before committing.

When to Consider This Package

Adopt when:

• You're on a modern Laravel version, small-to-mid team, and controllers have grown past the point where they're readable or testable.
• The team already believes in one-handler-per-action; you just need the wiring and the middleware pipeline.
• You want validation/logging/transaction middleware on write paths without inventing it per feature.
• You can pin a version and are genuinely prepared to vendor or fork. With 3 stars and 0 dependents, you are the maintainer in practice. Treat it as a starting point, not a strategic dependency.
• You're running a bounded pilot (one context, one sprint) with a clear fallback to plain injected service classes.

Look elsewhere when:

• You need async or queued commands, retries, backoff, or distributed workflows — Laravel's native bus with ShouldQueue, Symfony Messenger, or an explicit queue design fit better.
• You need domain events, event sourcing, or projections — this is commands and queries only.
• The team won't enforce the convention. A bus without discipline is just extra indirection and an extra file per action.
• Procurement, security review, or SLA/CVE response is required — there's no evidence of a maintainer bench, release cadence, or security process.
• The app is small. Two injected service classes will beat a bus on every axis.
• You're outside the supported Laravel range, or the framework-agnostic core is doing work you don't actually need.

How to Pitch It (Stakeholders)

For executives: This isn't a product feature — it's an engineering-hygiene choice with near-zero license cost (MIT) and a days-scale integration. It buys thinner controllers, faster tests, and a clean architectural seam if we later split modules into services. The risk is maintenance: by community standards the package is effectively unmaintained (3 stars, no dependents, single-maintainer risk). My recommendation is to approve it only as an internal, forkable pattern with a named owner and a one-day escape hatch back to plain Laravel services — not as a strategic dependency. Suggested gate: a one-sprint pilot in a single bounded context, with controller LOC and test-suite runtime measured before and after.

For engineering: One handler per command or query, explicit bindings, a middleware pipeline for validation/logging/transactions, container-injected handlers, and the ability to test by dispatching without HTTP. The core is framework-agnostic, so the pattern survives a framework move. The cost is boilerplate plus a convention you have to enforce in review; the benefit is controllers that read like a routing table and domain logic that's unit-testable in isolation. Vendor the code or wrap it behind an internal interface so we can swap the implementation without touching call sites.