Queries Doctrine Laravel Package

Product Decisions This Supports

This package is best treated as evidence for a design decision, not as a dependency decision. It is a small Doctrine ORM adapter for the useless-soft/queries query-bus abstraction — i.e., it lets read-side "query objects" be handled by Doctrine instead of scattering bespoke repository methods. At 2 stars, zero dependents, and archived status, the signal is too weak to justify a procurement or architecture commitment, but it is still useful input to the following decisions:

• Build vs. buy the read side. The package is small enough to be reimplemented in-house in a few hundred lines. Its main value is showing the seam: a QueryBus interface with per-storage adapters (Doctrine ORM, DBAL, Elasticsearch). That informs whether we standardize a query-object convention internally rather than adopting a vendor.
• Repository vs. query-object convention. If our roadmap includes complex filtered/sorted/paginated list endpoints (admin panels, reporting, internal tooling), the query-object pattern reduces controller and repository bloat. This package is a reference implementation of that convention, not the convention itself.
• Doctrine migration scoping. If we ever evaluate Doctrine ORM alongside Eloquent, this demonstrates what a Doctrine-backed read layer looks like. It does not justify a migration — Laravel does not ship Doctrine, so adoption implies an additional integration package and its own maintenance burden.
• Adapter abstraction for future read stores. If we anticipate introducing a search index or read-optimized store (Elasticsearch, read replicas), the sibling-adapter shape here is a cheap template for keeping handlers swappable without rewriting call sites.
• Feature scoping for CQRS-lite. It clarifies the boundary: queries are read-only, side-effect-free, and separately dispatchable — useful when deciding whether an endpoint belongs in a command handler or a query handler.

When to Consider This Package

Consider it only under a narrow conjunction of conditions:

• We have already committed to useless-soft/queries as our query bus and need the Doctrine ORM adapter specifically.
• We are prepared to fork it and own maintenance indefinitely — it is archived, and archives do not receive PHP version, Doctrine version, or security fixes.
• The license question is resolved. The repository reports NOASSERTION, which is a legal/procurement blocker, not a footnote; no production dependency should ship until counsel clears it.
• The code has been read end-to-end and its tests run against our PHP and Doctrine versions, and we accept the blast radius (small surface area, few transitive dependencies).

Look elsewhere — or build — when any of the following hold:

• We care about maintained dependencies. Archived + zero dependents means no upstream support, no CVE response, and no community answer when it breaks.
• We are Eloquent-first. Laravel does not ship Doctrine; pulling this in drags a Doctrine integration layer with it. The cost is architectural, not just a Composer line.
• We need a support commitment, SLA, or vendor accountability of any kind.
• We want the pattern without the baggage. A thin in-house query-bus (interface + handler resolver + a Doctrine handler base) is a better trade than adopting an unmaintained adapter.
• Alternatives worth benchmarking first: Symfony Messenger as a dispatch mechanism, Laravel pipelines for handler composition, Doctrine's own QueryBuilder/specification patterns, or the sibling useless-soft DBAL/Elasticsearch adapters if we ever go all-in on that bus.

How to Pitch It (Stakeholders)

Executives: This is not a vendor adoption proposal. The library is archived, has two stars, no downstream users, and an unclear license — so the recommendation is do not add it as a production dependency. Instead, treat it as a free design reference for a read-side query layer. Proposed ask: a 1–2 day spike to prototype an in-house query-object convention, versus an open-ended maintenance liability from forking an abandoned package. Expected outcome is a small, owned abstraction with no licensing or support exposure.

Engineering: The package demonstrates a clean query-bus-with-adapters seam worth copying: read-only query objects, one handler per query, storage adapters behind an interface. The code is small enough to review in an afternoon and to reimplement rather than fork. Risks to record explicitly: archived status (no patches), NOASSERTION license (legal review required before any code reuse — including copy-paste, not just Composer), zero dependents (no field validation), and Doctrine-in-Laravel integration cost (an extra integration package, dual persistence models, team ramp-up). Recommendation: reference-only, with a short internal build if the pattern earns its place in a real feature.

Decision requested: Approve the spike; decline the dependency. Revisit only if the parent queries package is revived and actively maintained, or if we formally adopt Doctrine as a persistence layer.