Command Dispatcher Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy on the command bus layer. This package is a thin, MIT-licensed wrapper that wires a command dispatcher into a Symfony container. It informs the decision of whether to adopt an off-the-shelf dispatcher or write a ~200-line internal CommandBus + handler locator. The latest release — 0.4.1, a composer.json dependency fix and nothing else — is a maintenance hygiene patch, not a revival: no new features, no API changes, no support commitment. The honest PM read is unchanged: it is a reference implementation, not a dependency. Use it to scope the build, not to replace it.
• CQRS-lite / action-handler architecture adoption. If the roadmap includes decoupling write operations (commands) from controllers/services into single-purpose handler classes with a middleware pipeline (logging, transactions, validation, auth, idempotency), this package defines the shape of that layer: one dispatcher service, attribute- or tag-based handler registration, container autoconfiguration.
• Framework fit check (critical). The package targets Symfony, not Laravel. If the product is Laravel-based, this is a non-starter for direct adoption; it only contributes the pattern. If the estate is Symfony, it becomes a candidate for a bounded internal service.
• Feature and refactor sequencing. Adopting a command bus is an architectural investment that pays off only when there is a critical mass of write use cases (checkout, onboarding, billing events). It should be scheduled alongside — not before — a real domain refactor, otherwise it adds indirection with no payoff.
• Vendor/abandonment risk modeling. A single dependency-hygiene commit does not change the risk profile: the package still has effectively no downstream adoption and a single-maintainer cadence with a multi-year gap between functional releases. Any adoption decision must carry an explicit "we may own this forever" line item in the engineering budget. MIT license makes forking viable; the PM decision is whether forking is a cost we accept. Note that a composer.json-only patch signals housekeeping, not maintenance — it does not imply the bundle will track future Symfony majors.

When to Consider This Package

Consider it (or, more realistically, its pattern) when:

• The platform is Symfony 5/6-era and the team already has or wants attribute-driven autoconfiguration for services. The 0.4.1 composer fix may ease install-time constraint conflicts, but it does not extend framework-version support.
• You need a lightweight command bus without pulling in a full messaging transport, async workers, or a broker. If you need queues, retries, or distributed handling, use Symfony Messenger instead — it is maintained, first-party, and covers the same dispatch path plus transports.
• You want to read a small, complete implementation to inform an internal CommandBus interface and handler-discovery convention.
• The use cases are synchronous, in-process, single-tenant write operations where the overhead of a dispatcher is justified by testability or cross-cutting middleware.

Look elsewhere — and treat this as do not adopt — when:

• The stack is Laravel. Laravel's service container, pipeline, and job dispatch already cover 80% of this; a stale Symfony bundle adds nothing but a porting cost.
• You need active maintenance, security patching, or a support SLA. A dependency-only patch release after a long dormancy is not evidence of a support commitment; it remains a hard stop for anything on a revenue path.
• You need async, event-driven, or distributed command handling — Symfony Messenger or a managed queue is the correct answer.
• You need documented upgrade paths across framework majors. A single-maintainer bundle with no functional release history will likely not survive a Symfony 6→7 migration unassisted.
• Your team has no existing CQRS conventions. Introducing a dispatcher without handler naming, validation, and transaction-boundary standards produces inconsistency, not architecture.

How to Pitch It (Stakeholders)

For executives: We re-checked a small open-source command dispatcher after a new patch release. The release contains a single change: a fix to its Composer dependency declarations. There are no new features, no security work, and no signal of ongoing support — it is one maintainer doing housekeeping. Our recommendation does not change: build the capability, use this as a reference design, do not vendor it into the product. The capability is genuinely small — roughly one engineering week to implement and own internally — so we are not blocked.

For engineering: Version 0.4.1 is a composer.json dependency fix only. It changes nothing about the API, the middleware surface, or framework-version compatibility. It is useful as a design sketch for an internal CommandBus, middleware pipeline (transaction, logging, validation), and one-handler-per-command convention. It remains unsuitable as a dependency: single maintainer, no meaningful downstream adoption, no functional release in years, and no evidence it will track Symfony major-version upgrades. If we need async or retries, standardize on Symfony Messenger rather than this bundle. If our stack is Laravel, this is pattern-only — our container and pipeline already give us the primitives.

Decision requested: Approve a small internal spike to define our own command/handler contract, with this package and Symfony Messenger as the two reference points; defer any external adoption until we have a documented handler convention and at least three concrete write use cases to justify the layer.