Command Bus Bundle Laravel Package

Product Decisions This Supports

• Whether to introduce a command bus at all. The core architectural question — do we route writes through explicit Command → Handler pairs instead of fat controllers/services — is a roadmap-level decision with downstream effects on how every write-side feature gets built. This package is a reference implementation of that pattern, useful as a design input even if never installed.
• Build vs. buy for cross-cutting write-side concerns. A command bus is the natural seam for transactional wrapping, validation, authorization, audit logging, retry/idempotency, and async dispatch. If the roadmap includes any of: audit trails for compliance, background job processing for slow writes, or event-driven integrations, the bus is where those attach. Deciding to adopt one is really deciding to standardize those concerns behind a single interface.
• Decomposition and team-scaling decisions. A command bus is often adopted as a precursor to CQRS or modular monolith boundaries. Choosing it commits teams to a convention (one handler per command, no handler-to-handler calls) that shapes code review standards and onboarding.
• Refactor vs. rewrite sequencing. If we're considering extracting write paths out of legacy controllers, the existence of a mature, maintained bus library affects whether that refactor is a 2-week task or a multi-month framework project.
• Feature-level use cases it enables: checkout/order placement pipelines with compensating actions, bulk import jobs dispatched to queues, admin actions requiring an audit record, and integrations where a single user action fans out to several side effects that must be transactional.
• What it does not support: any decision requiring vendor support, a security response commitment, or compatibility with the current runtime. Treat this repository as documentation of a pattern, not as a candidate dependency.

When to Consider This Package

Consider it only in these narrow circumstances:

• As a reading reference. You want a small, complete example of a command bus (bus, command interface, handler resolution, handler invocation) to inform an internal design or a spec for a homegrown implementation. It is small enough to read in an afternoon, which is its main remaining asset.
• You are on a legacy Symfony 2.x/3.x application pinned to PHP 5.6–7.0, the app is in maintenance-only mode, and you need a minimal bus to consolidate write paths before a migration. Even here, the package is a stopgap to be replaced, not adopted.
• You want to evaluate the pattern cheaply before committing to a heavier framework-native alternative.

Look elsewhere — decisively — when any of the following is true:

• Framework mismatch. This is a Symfony bundle, not a Laravel package. It has no service provider, no facade, no Laravel container integration. Adopting it in a Laravel codebase means writing the entire integration layer ourselves, which is the same work as writing the bus ourselves, minus the ability to fix the parts we don't like.
• Maintenance and risk posture. Last release January 2016; effectively a decade of drift. Zero stars and zero dependents means no community, no issue triage, no forks carrying patches, and no one to ask when it breaks. There is no security disclosure process, so any vulnerability is ours to find and patch in a vendored copy.
• Runtime compatibility. A 2016 Symfony bundle predates PHP 7 type declarations, PHP 8 union types, attributes, and modern Symfony's container/autowiring contracts. Expect it to be incompatible with current PHP and framework versions without patching — at which point you own a fork.
• You need production capabilities. The package provides the dispatch mechanism and essentially nothing else: no first-party middleware for transactions, retries, queuing, idempotency, or tracing. Those are the reasons to have a bus in the first place.
• Non-negotiable requirements exist around support SLAs, license review, or dependency provenance. A single-maintainer, abandoned, zero-adoption package will not clear those gates.

The realistic conclusion for a Laravel shop: build the bus in-house (it is a few hundred lines and gives full control over middleware), or use a maintained, framework-native alternative. The decision is not "this package or nothing" — it is "this package or a thin internal implementation," and the internal implementation wins on every axis except initial effort.

How to Pitch It (Stakeholders)

For executives — the one-paragraph version: We evaluated a third-party library for routing write operations through a structured command handler pattern. It is unmaintained (last release 2016), has no users we can identify, no security response process, and targets a different PHP framework than ours. I do not recommend adopting it as a dependency. The pattern it represents is worth adopting, and we can implement it internally in roughly one to two weeks with full ownership and no supply-chain exposure. Net recommendation: adopt the pattern, reject the package.

For engineering leadership: The business case for a command bus is real — it gives us one place to enforce transactions, authorization, audit logging, idempotency and async dispatch across every write path, which directly reduces duplicated logic and makes compliance features cheaper to add. The commercial case for this library is not: zero adoption, no releases in nine years, no maintainers, and a Symfony bundle in a Laravel estate. Integrating it would cost more than writing our own, because we'd have to shim the container, patch for modern PHP, and then maintain a fork with no upstream to merge from. Owning a ~300-line internal bus plus our own middleware gives us the same architecture with a supportable dependency graph and the freedom to evolve it with our roadmap.

Questions this answers for the roadmap:

• Do we standardize write-side plumbing now, while the surface area is manageable, or keep absorbing duplication per feature?
• Is the audit/retry/async work already on the roadmap? If yes, the bus is the cheapest place to land it, and the timing argument for doing it this quarter is strong.
• Are we comfortable taking on ~1–2 weeks of internal build to avoid an unsupportable dependency? (Recommendation: yes.)

What I need from you: approval to spike an internal command bus (timeboxed, one sprint, measured against two real write paths — checkout and bulk import) rather than pursuing third-party adoption. Success criteria: no regression in either path, middleware for transactions and audit in place, and a clear migration note for the next feature team.