Command Bus Laravel Package

Product Decisions This Supports

• Architecture pattern evaluation, not a feature purchase. This package is a reference implementation of the command/handler pattern: one class per user intent (e.g. RegisterUser, CancelOrder), a handler per command, and a middleware pipeline for cross-cutting concerns (transactions, logging, authorization, validation). The decision it informs is "do we structure our write paths this way?" — not "which library do we install?"
• Build vs. buy → build. At ~0 stars, ~0 dependents, and archived status, the rational outcome of any evaluation here is an in-house command bus of roughly 100–200 lines: a command→handler map resolved through the container, plus a middleware chain. That is comparable in scope to the package's own surface area and carries no supply-chain obligation.
• Roadmap: Laravel already ships this capability. Laravel's own Illuminate\Bus\Dispatcher (reachable via the dispatch() helper and the Bus facade) is a command bus — it handles handler resolution, queuing, and middleware via pipe()/through(). Any roadmap item framed as "introduce a command bus" should first be re-framed as "enforce one-command-one-handler conventions on top of the dispatcher we already pay for." This package adds nothing to that story.
• Use cases where the pattern earns its keep: transactional write boundaries (wrap handler + persistence + event dispatch in one middleware), audit trails per intent, queueing expensive writes, and test seams where a handler can be swapped or mocked. All of these are achievable with framework primitives.
• Use cases where it does not: simple CRUD services, small teams without a shared vocabulary for commands, or codebases where a bus becomes an indirection tax (handler-per-endpoint explosion with no middleware benefit).

When to Consider This Package

Read it, don't depend on it. The only defensible adoption here is as a ~30-minute architectural read for a developer designing an internal bus — seeing how a minimal implementation separates the map, the handler resolution, and the middleware chain.

Criteria that would normally gate adoption of a command bus library, and how this one fails them:

Look elsewhere — specifically:

• Laravel's native dispatcher for anything already inside a Laravel app. Zero new dependencies, first-party support, queues and middleware included.
• symfony/messenger if you need a bus that spans HTTP and async workers with retry/transport semantics, or if the app is not Laravel-bound.
• A small internal implementation if you want strict typing on the command→handler map and full control over the middleware contract.
• Note that the other well-known PHP option, league/tactician, is also archived — treat "the command bus library" as a category with no strongly maintained default outside the frameworks themselves, which strengthens the build case.

How to Pitch It (Stakeholders)

To executives (one paragraph): We evaluated a command bus library for structuring our write operations. It is archived, has no measurable adoption, and offers no support or security-patching path — while the capability it provides is already built into Laravel, which we pay for and patch. Recommendation: do not adopt. If we want the architectural discipline, an engineer can reproduce the useful part in a day, with no new third-party dependency and no vendor risk. Net cost of adoption exceeds net cost of building, and the build option is small.

To engineering (the actual pitch): The pattern is worth stealing; the dependency is not. Adopt three conventions on top of Illuminate\Bus: (1) one command class per user intent, named as a verb phrase, immutable and constructor-validated; (2) exactly one handler per command, registered explicitly rather than by convention-scanning, so the map is greppable; (3) a middleware stack owning transactions, authorization, and logging, so handlers contain only domain logic. Wrap dispatch behind a thin application-level interface so tests can assert on intent rather than on framework calls. That gives us the testability and transactional-boundary benefits, keeps us on a supported dependency, and leaves the door open to symfony/messenger later without touching call sites. Estimated effort: one to two days, including the interface and middleware. The archived package's only remaining value is as a sanity check on our design — read it once, then close the tab.