Command Bus Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for CQRS scaffolding. Laravel already ships an application bus with ShouldQueue, Bus::batch, and pipeline middleware. What this package adds is the opinionated command/handler contract plus ergonomics — a savings measured in days, not weeks. That reframes the decision from "adopt an architecture" to "adopt a small helper," and small helpers are cheap to build and cheap to drop.
• Scoping an incremental CQRS migration. If the roadmap contains "untangle fat controllers / fat services," a command bus is the cheapest first step: one named seam per use case, no commitment to event sourcing, read models, or extra infrastructure. This package is the lowest-commitment option on the table.
• Async / AMQP use cases. Where the roadmap offloads work to a broker (notifications, report generation, third-party syncs), the "AMQP-powered messaging" claim is the only real differentiator. Treat it as a diligence item, not a selling point — it is unverified.
• Architecture standardization across teams. A shared "controller → command → handler" convention lowers review friction and makes new engineers productive faster. The value is in the convention, not the code, and a convention can be adopted with or without this package.
• Extension-surface decisions. Whether to expose middleware, logging, and custom transports as product-level extension points or keep them internal. At 0.x, keep them internal.
• Roadmap sequencing and gating. Any roadmap item that depends on this inherits single-maintainer and pre-1.0 risk. It should not appear as "introduce CQRS" until a spike confirms it works on our Laravel version.

When to Consider This Package

Consider it when:

• The team is already Laravel-fluent and already wants command/handler separation. This is a convention layer, not a teacher.
• Runtime is PHP 8.2+, and the composer.json delta is confirmed as widening rather than excluding. The one-line release note does not say, and the two outcomes have opposite consequences.
• The need is a thin bus with container-resolved handlers and a middleware pipeline, and the AMQP claim is validated against a real broker in a spike.
• You accept the operating cost: exact-version pinning, diff review on every 0.x release, and one named owner for dependency review.
• A fork/vendor plan exists. At 0 stars with a single maintainer, "we can maintain this ourselves" must be true before it touches a request path.

Look elsewhere when:

• The framework match is unclear — and right now it is. Repository metadata describes a Symfony bundle for command bus; the integration review treats it as a Laravel package. For a Laravel estate, that discrepancy is a stop-and-verify item, not a footnote. If it is genuinely Symfony Messenger-based, the bridging cost changes the build-vs-buy math entirely, and Symfony Messenger is the more defensible choice for a Symfony-leaning shop.
• Laravel's native bus, queues, and pipelines already cover the need. This is the honest default for most teams: free, supported, already installed.
• The bus would sit on a request path or handle persistence. Zero stars, one maintainer, one-line release notes, pre-1.0 — there is no support posture to lean on.
• You need a deprecation policy, security disclosure process, or SLA. None is evidenced.
• You are on PHP 8.1 or earlier and unwilling to upgrade. Do not bridge with --ignore-platform-reqs.
• The real goal is event sourcing or full CQRS with read models. This is a bus, not a CQRS platform, and would be mis-sold as one.

How to Pitch It (Stakeholders)

Executives: "A small, low-cost library that standardizes how we structure business logic and lets us move work off the request path. It's a one-day evaluation, not a platform migration. My recommendation today is a time-boxed spike, not adoption — the maturity signals (no community, single maintainer, one-line release notes) are too thin to bet a customer-facing feature on."

Engineering leadership: Frame it as a convention layer over the framework's existing bus. The pitch is consistency and a clean controller/handler seam, with an explicit acceptance that pre-1.0 means pinned exact versions and a diff review per release. Assign one owner. If the spike shows the AMQP transport is real and the Laravel constraint is current, this is a reasonable prototype dependency; production approval waits on that evidence.

Engineers: "You get a named command per use case and a handler the container resolves for you, instead of another 400-line service class. We'll wrap package calls behind a thin application-level adapter so a 0.x API change is a one-file fix." Be honest that this is unproven at 0 stars and that we may end up dropping it for the framework's own bus.

The caveat to put in writing before anyone gets excited: the repository describes itself as a Symfony bundle while our evaluation assumes Laravel. Resolve that in the first hour of the spike. It is the cheapest test with the highest chance of killing the initiative — and finding out early is the win, not the failure.