Command Bus Bundle Laravel Package

Product Decisions This Supports

• CQRS-lite / write-path architecture. Supports the decision to model each write as a discrete command object routed to exactly one handler, with cross-cutting concerns (transactions, validation, auth, audit logging, domain-event dispatch) attached as middleware rather than scattered across controllers and services — a good input to any "write-path consistency" or "tame fat controllers" initiative.
• Build vs. buy vs. copy. At ~0 stars, 0 dependents, and a single maintainer, the honest framing is "vendor or fork ~100–300 lines of container glue" rather than "adopt a dependency." This package's real value is as a design reference for command-to-handler wiring, not as a library to pull into composer.json.
• Framework direction. Despite being catalogued as a Laravel/PHP package, this is a Symfony bundle (bundle class, DI extension, compiler passes, service tags). Laravel has no bundle/container-compiler concept. This is a data point for a "Symfony vs. Laravel / stay framework-native" decision and should trigger an upstream correction before it lands in a Laravel dependency backlog.
• Dependency-tier policy. Zero adoption, zero dependents, bus factor of 1 makes this a tier-3 "reference only" artifact. Useful for establishing a policy where critical write paths require first-party or well-adopted components.
• Roadmap scoping. Best consumed as a half-day spike to align the team on command-bus semantics before standardizing on framework-native tooling — a cheap way to de-risk an architecture conversation without committing to a vendor.

When to Consider This Package

Consider it when:

• You are on Symfony and want a minimal, readable command bus without the surface area of Symfony Messenger.
• You want a teaching/reference artifact to align the team on command → handler → middleware semantics before writing your own implementation.
• It's a prototype, internal tool, or spike where abandoned-dependency risk is acceptable and the code is small enough to fork.
• Your stance is explicitly "read the compiler pass and service definitions, then reimplement."

Look elsewhere when:

• You're on Laravel. Container/DI semantics don't map; use Illuminate\Bus (dispatch(), Bus::chain()/batch(), ShouldQueue, bus middleware). This is a disqualifier, not a tradeoff.
• You need async, transports, retries, failure queues, or scheduling — Symfony Messenger (or Laravel's native bus) is first-party and maintained.
• The write path carries SLAs, audit, or compliance requirements. Zero dependents and a bus factor of 1 fails any reasonable dependency review for critical paths.
• You need a middleware ecosystem (Doctrine transaction middleware, retry policies) — prefer official or widely adopted components.
• No visible releases, CI, or tests — you'd be inheriting maintenance, not outsourcing it.

How to Pitch It (Stakeholders)

To executives: Don't adopt this as a dependency. The underlying pattern — a command bus that centralizes transactional and cross-cutting logic for write operations — is sound and reduces coupling. This particular package has zero community adoption and a single maintainer, which is unacceptable for anything on a critical path. Recommendation: a small, time-boxed engineering slice (a few engineer-days) to standardize our write path using framework-native tooling, using this repo purely as a design reference. Expected outcome: fewer defects around partial writes and a simpler audit story — cost is engineer-days, not a new vendor relationship.

To engineering: Treat this as a reference implementation, not a library. Read the bundle's service definitions and compiler passes to see how a command bus is wired into a container, then replicate the pattern with our own handlers and middleware — or use the framework-native bus (Symfony Messenger / Illuminate\Bus), which gives the same abstraction plus async, retries, and queuing for free. If anyone still wants it as a dependency, pin/vendor/fork it and keep it off the critical write path. Also flag the mismatch: the ticket says Laravel, the package is Symfony-only — please reconcile before this reaches a backlog.