Cqrs Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for CQRS plumbing. The decision isn't really "adopt this bundle"; it's "do we hand-roll command/query buses, handler registration, and middleware in every Symfony service, or standardize on a library?" This bundle (glue around lmc/cqrs) is the buy option. It gives you service tagging, compiler passes, and middleware configuration out of the box — worth scoping an in-house estimate against before deciding.
• Incremental architecture roadmap. CQRS adoption fails when it's a big-bang rewrite. The bundle lets you introduce a command bus for one bounded context (e.g., checkout, onboarding) while reads stay on the existing ORM/repository layer. That supports phased delivery commitments rather than a single risky "modernize the architecture" epic.
• Feature separation and auditability. Command/query separation is a forcing function: writes carry validation, invariants, transactions, and domain events; reads stay fast and side-effect free. That directly enables features product teams ask for — audit trails, reliable domain events for downstream integrations, async job dispatch — without bolting them onto controllers.
• Cross-team standardization. If multiple squads own Symfony services, a shared handler/bus convention cuts bespoke boilerplate and review friction. Low direct user value, real velocity and onboarding value.
• Risk budgeting. 1 star, 0 dependents, single-vendor stewardship (LMC), and 2.0 — the current release — dates to May 2022. Treat it as a source dependency you may own, not a vendor-supported platform. That framing shapes whether the decision is "adopt," "fork," or "spike only." Note that 2.0 is itself a breaking release: any team still on 1.x inherits a migration, not a drop-in upgrade.

When to Consider This Package

Consider it when:

• You are on Symfony 5.2–6.x and PHP 8.1+. 2.0 adds Symfony 6 support, requires PHP 8.1, and drops Symfony 4.4 and 5.1 — verify your runtime matrix before anything else.
• You specifically want the lmc/cqrs model of explicit, synchronous, in-process buses with a middleware pipeline for logging, transactions, and validation.
• You want something lighter than Symfony Messenger: no transports, no workers, no routing config — just dispatch-and-handle.
• You need a small, auditable dependency surface and are prepared to fork and maintain it (MIT makes that legally trivial).
• You are starting fresh on 2.0 rather than upgrading from 1.x — the [BC] method-signature changes make greenfield adoption materially cheaper than migration.
• You are running a time-boxed spike to validate CQRS conventions before committing to a longer-term approach.

Look elsewhere when:

• You need async processing, retries, transports, scheduling, or failure queues — Symfony Messenger is first-party, actively maintained, and the safer default. Most teams evaluating this bundle actually want Messenger.
• You need maintenance guarantees, security patching SLAs, or a support contract. Stale since 2022 with near-zero external adoption means no community safety net.
• You need event sourcing, sagas/process managers, or projection rebuilds — this is a bus/handler layer, not an event-sourcing framework.
• You are stuck on PHP < 8.1 or Symfony 4.4/5.1. 2.0 cannot run there, and the 1.x line no longer receives Symfony 6 support — you are pinned to an older, unmaintained branch.
• You are not on Symfony — evaluate the underlying lmc/cqrs library directly, or a maintained alternative.
• Your team has no CQRS experience and no senior engineering sponsor. The bundle provides wiring, not guidance; the conceptual cost lands on delivery.

How to Pitch It (Stakeholders)

Executives: This is a small, MIT-licensed glue package, not a strategic platform bet. It reduces boilerplate for separating reads from writes in our Symfony services, which makes write paths easier to audit and makes event-driven features cheaper to add later. Risk is low to evaluate (small surface, permissive license, no vendor lock-in) but external validation is effectively zero: one star, zero dependents, and 2.0 — the newest release — is from May 2022. Recommendation: fund a short spike in a non-critical bounded context, assume we may own the code long term, and keep Symfony Messenger as the sanctioned path for anything asynchronous. Do not build a multi-quarter roadmap on this dependency.

Engineering: The value is convention over configuration — tagged handlers, a configured command/query bus, and a middleware pipeline you can hook for transactions, logging, and validation. The cost is that you inherit maintenance: pin the version, read the source (it's thin), and budget for a fork if upstream stays quiet. 2.0 sets the floor at PHP 8.1, targets Symfony 5.2–6.x, and carries [BC] method-signature changes from 1.x — so confirm our runtime matrix and read the upgrade diff before committing. Be explicit about the boundary — this handles in-process dispatch only; async, retries, and transports belong to Messenger.