Queries Bundle Laravel Package

Product Decisions This Supports

• Read/write separation (CQRS-lite) — go/no-go. This bundle exists to wire a query bus into Symfony's DI container: one service for dispatching queries, auto-registration of handlers, no controller-to-repository coupling. That makes it a useful reference point when deciding whether our read path deserves the same structure as our write path, or whether plain autowired services are enough.
• Build vs. buy for the read layer. Informs the choice between (a) buying into a query-bus abstraction, (b) using Symfony Messenger's bus with a dedicated query bus and HandleTrait, or (c) building a thin in-house dispatcher. The bundle's feature surface is small — which is exactly the kind of scope we could own in a sprint if the pattern proves worth it.
• Roadmap sequencing for handler conventions. If we adopt any query bus, we're also committing to conventions: one handler per query, naming rules, where query DTOs live, how handlers get tagged. That's a standards decision affecting onboarding and review checklists, not just a dependency choice.
• Use-case scoping. Concretely relevant to read-heavy surfaces: dashboards, reporting endpoints, list/detail API responses, BFF read models, and anywhere we want per-query routing (read replica vs. primary, cache-vs-DB) without leaking that logic into controllers.
• Dependency-health input to the risk register. With 1 star, 0 dependents, and an archived repository, this is a data point for our policy on unmaintained third-party code: what we allow in prototypes vs. what we allow in anything customer-facing.

When to Consider This Package

Consider it only in a narrow band:

• You are already committed to useless-soft/queries as the core query abstraction and want Symfony container integration rather than hand-wiring the bus and handler map.
• The work is a prototype, internal tool, or throwaway spike where "archived upstream" carries no support obligation.
• You have verified compatibility yourself — PHP version, Symfony version, DI compiler-pass behavior — because an archived repo will not tell you when it breaks. Expect to pin the version and treat any fix as a fork you own.
• Someone on the team has read the source and is comfortable maintaining it. It's small enough that this is realistic; that is the only thing making it defensible.

Look elsewhere — and default to elsewhere — when:

• The code is production or customer-facing. Archived + 1 star + 0 dependents means no security patches, no Symfony major-version compatibility work, and no answers when it fails at 2 a.m.
• Symfony Messenger is already in the stack. A dedicated query bus with HandleTrait, middleware for logging/metrics, and sync transport covers most of this with a dependency we already run and patch.
• You need async queries, middleware pipelines, retries, or observability out of the box; this bundle's value proposition is thin wiring, not operational features.
• You need documented behavior, upgrade guides, or a support channel — none of which exist here.

How to Pitch It (Stakeholders)

One line: The pattern is worth a look; the package is not — it's archived with essentially zero adoption and should be treated as a design reference, not a dependency.

For executives: This is a small Symfony integration package for a query-bus pattern (separating "read this data" requests from business logic). Adopting it would save us a few days of wiring at the cost of owning an unmaintained dependency indefinitely. My recommendation is to not adopt it; if we want the pattern, we implement it on Symfony Messenger, which we already run and patch.

For engineering: Read it as documentation of how a query bus maps onto Symfony's container — service definition, handler tagging, dispatch surface. If we want the pattern, we get ~90% of the value from a Messenger query bus plus a HandleTrait-based dispatcher, with middleware for logging and metrics thrown in. If a team wants to spike the original in a prototype, fine — pinned version, no production path, and a note in the risk register. Any production use requires a named owner and a fork we maintain.

Decision requested: No adoption. Approve the pattern as an option in the read-layer design discussion, and standardize on Symfony Messenger as the implementation vehicle if we go that way.