Cqrs Handler Laravel Package

Technical Evaluation

Architecture fit. Unchanged in substance: the package remains a base implementation for CQRS types — contracts and thin abstractions for commands, queries, and handlers, not a framework. 2.3.0 reinforces that positioning rather than altering it. The addition of Symfony 8 support is a useful signal: the maintainers are deliberately keeping the package framework-agnostic and are investing in a second integration surface. That is consistent with our read of it as a convention layer, and it slightly improves the odds that the abstractions are genuinely portable rather than Laravel-shaped by accident. It does not give us a Laravel service provider, handler discovery, or bus implementation — we still own all of that. Value remains concentrated on the query side and on enforcing a consistent cross-module vocabulary.

Integration feasibility. Mechanically unchanged: composer require, implement interfaces on DTOs, write handler classes, add a small adapter resolving handlers from Laravel's container. Still ~1–3 engineer-days for a proof of concept. One new feasibility check is now mandatory before we commit: does 2.3.0's Symfony 8 support change the package's PHP floor or pull Symfony components as hard dependencies? Symfony 8 targets PHP 8.4, so a careless require (rather than require-dev/suggest) could force our runtime PHP version up or drag in symfony/* packages we don't want alongside Laravel. Verify composer.json constraints and run composer why symfony/console (or equivalent) in the spike. If Symfony support is correctly optional, integration cost is unchanged; if not, it's a blocker for Laravel 10/11 shops on PHP 8.1–8.3.

Technical risk. Still high on adoption signals, but marginally improved:

• Ecosystem validation remains effectively nil (1 star, 0 dependents). 2.3.0 does not change this.
• Maintenance signal improved. A feature release with framework-version support is a meaningful counter-signal to abandonment. Someone is tracking upstream framework releases and cutting versions. This is a better indicator than star count.
• New risk introduced by 2.3.0: dependency-constraint creep. Adding a framework major (Symfony 8) in a minor version is semver-legal only if the dependency is optional. Confirm it is. Also confirm Symfony 8 didn't bump the package's own php constraint.
• The release-date anomaly persists: 2.3.0 is dated 2026-06-04 and the prior release was dated 2026-09-04 — internally inconsistent ordering. Treat release metadata as unreliable; verify against Packagist tags and CI runs directly.
• Mitigants unchanged and still decisive: MIT license, small surface area, forkable in a day. Low blast radius.

Key questions.

1. What exactly ships — interfaces only, or concrete bus/handler-map implementations? Does it assume a PSR-11 container?
2. Supported PHP versions and the Laravel compatibility matrix; is there CI and test coverage?
3. Is it used in production at LMC? Is the public repo a mirror of a more actively maintained internal package?
4. (Partly answered by 2.3.0) There is no Laravel-specific integration path; the intended integrations are generic PSR-11 plus Symfony. Is a Laravel service provider on the roadmap, or explicitly out of scope?
5. New: Is symfony/* a hard or optional dependency in 2.3.0, and did the Symfony 8 work raise the minimum PHP version?
6. New: What is the Symfony 8 constraint syntax (^7.0|^8.0 vs ^8.0)? A hard ^8.0 would drop compatibility with older Symfony and signal a willingness to take hard major-version stances in minor releases.
7. What is the BC policy, and does the package expose enough extension points (middleware/decorators) for transactions, logging, and authorization without patching?
8. How does it relate to Laravel's native bus — complementary or duplicate?

Integration Approach

Stack fit. Laravel 10/11/12 on PHP 8.1+ remains the target. 2.3.0 confirms the package will not fight Laravel's container, service provider, or queue system — and equally confirms it will not use them for us. The Symfony 8 work is a mild positive for portability but delivers nothing to a Laravel codebase directly. The Illuminate\Bus collision still needs an up-front decision: keep Laravel's dispatcher for queued/side-effect commands, use this package for the query path and CQRS contract enforcement in new modules.

Migration path. Unchanged and still the right call: greenfield modules only, behind our own App\CQRS\CommandBus / App\CQRS\QueryBus interfaces. 2.3.0 slightly strengthens the case for this adapter — a package with a Symfony integration surface is more likely to evolve its abstractions in ways that serve Symfony first. Our internal interface keeps that evolution from reaching our domain code.

Compatibility. Add to the previous checklist: audit composer.json for Symfony constraints and php constraint changes between the version we evaluated and 2.3.0; diff the two releases if a changelog is thin. Confirm no transitive dependencies are pulled in. We still own container wiring and handler registration; prefer an explicit handler map (or attribute discovery) over convention-over-magic so failures are loud and static analysis can trace command→handler.

Sequencing.

1. Spike (1–2 days): read the full source at 2.3.0, run the test suite, diff against the prior version, and specifically resolve the Symfony dependency-constraint question. Wire one command and one query end-to-end in a scratch branch.
2. Decision gate: if the source is clean, interfaces are sane, and Symfony support is genuinely optional, proceed at ~2.3. If it is stub-level, undocumented, or drags in a PHP/Symfony constraint we can't accept, vendor the ~200 lines under our namespace and skip the dependency.
3. Adapter layer (2–3 days): internal interfaces, service provider, handler map, transaction and logging decorators.
4. Pilot (1 sprint): one bounded context with an ADR documenting conventions and the pinned version.
5. Broaden or roll back based on pilot retro; pin exactly (~2.3 with lockfile discipline, no floating ranges).

Version note. We evaluated pre-2.3; if the spike proceeds, target 2.3.0 specifically and record it in the ADR. Do not float across the Symfony-constraint change without re-reading composer.json.

Operational Impact

Maintenance. Low code volume; we still absorb 100% of glue code and convention drift. Budget ~1 day/quarter for PHP/Laravel upgrade compatibility checks and pin the exact version. 2.3.0 modestly improves the maintenance outlook — a release that tracks upstream framework versions suggests someone is watching the ecosystem. It does, however, add one more axis we must monitor: the package's Symfony and PHP constraints can move independently of Laravel's, so a routine composer update could surface a conflict originating upstream. Keep the lockfile pinned and update deliberately.

Support. No vendor SLA, no commercial backing, community issues only on a low-visibility repo. Effective support model remains internal ownership: name a maintainer, record the fork/vendor contingency in the ADR. The 2.3.0 release is a point-in-time signal, not a support commitment — do not let it lull the team into treating the package as externally maintained.

Scaling. Unchanged. In-process dispatch; the library is not a scaling factor. Synchronous handlers keep latency predictable but couple request time to handler work. Anything slow or I/O-heavy goes through Laravel's queue, which this package does not abstract. Keep handlers small, push heavy work to jobs, and watch for handler bloat and hidden N+1s in query handlers once teams get comfortable.

Failure modes.

• Unregistered handler → runtime exception at dispatch; mitigate with a boot-time assertion that every command/query in the handler map resolves.
• Container resolution errors for handlers with constructor dependencies.
• Dependency constraint conflict (new): a minor release tightening PHP or Symfony constraints breaks our composer update; mitigated by pinning and by reviewing composer.json diffs on every bump.
• Silent divergence: teams bypassing the bus and calling handlers directly.
• Upstream abandonment or an unexpected breaking change in a minor release (2.3.0 shows the maintainers will take major-dependency stances inside minors); mitigated by pinning and the adapter layer.
• Duplicate buses (Illuminate\Bus vs. this) causing confusion about where middleware and transactions apply.

Ramp-up. Low technical ramp — a Laravel developer grasps command/handler in under a day. The real ramp is convention: where validation lives, what a handler may return, when to queue, how queries differ from Eloquent scopes. Documentation is likely still thin, and the Symfony-facing release notes tell us nothing about Laravel usage, so invest in a short internal README plus one reference module. Expect ~1 day per developer, ~2 days of upfront enablement, and 2–3 sprints before the pattern is used consistently rather than ceremonially.

Bottom line for the TPM: 2.3.0 is a maintenance-positive, non-breaking release that confirms the package is a portable convention dependency rather than Laravel infrastructure. It does not change the recommendation — bounded pilot, behind an internal interface, with a named owner and a standing willingness to vendor it — but it adds one concrete gate before we commit: verify the Symfony 8 support did not raise our PHP floor or pull in hard dependencies.