Queries Doctrine Laravel Package

Technical Evaluation

Architecture fit

useless-soft/queries-doctrine is a narrow adapter: it bridges the UselessSoft queries abstraction (query objects dispatched to handlers) onto Doctrine ORM/DBAL. That is an intrinsically Symfony/Doctrine-shaped architecture, not a Laravel one. Laravel's default persistence layer is Eloquent, so this package only becomes relevant if the target application already runs Doctrine through laravel-doctrine or is being ported from a Symfony codebase. In a greenfield Laravel product it introduces a second ORM paradigm alongside Eloquent, which raises cognitive and onboarding cost without buying proportionate capability.

The package is also a thin integration layer, not a framework. Its value is entirely contingent on adopting the parent queries library first — meaning the real architectural decision is "do we adopt the UselessSoft query-bus pattern," and this package is a downstream consequence of that decision.

Integration feasibility

Low. Objective signals are disqualifying or near-disqualifying:

• Archived upstream — no bug fixes, no PHP/Doctrine version bumps, no security response.
• 2 stars, 0 dependents — no production validation anywhere in the ecosystem; you would be the first meaningful adopter.
• License NOASSERTION — GitHub could not classify the license. This is a hard blocker for legal review and for any redistribution or SaaS compliance audit until resolved manually.
• Score 0.065 — composite health is effectively at the floor.

Technical risk

High and concentrated in three areas: (1) dependency drift — Doctrine ORM 2.x → 3.x and DBAL 3 → 4 contain breaking changes this archived package will never track; (2) license ambiguity — unresolved provenance can block release; (3) transitive supply-chain exposure — an unmaintained leaf package pins unmaintained constraints.

Key questions

• What PHP, Doctrine ORM, and DBAL versions does the pinned composer.json allow, and is any of that still supported?
• What is the actual license text, and does it permit internal commercial use and redistribution?
• Does the parent queries library have independent health, or is it equally abandoned?
• What does this adapter provide that a 50-line repository layer or a first-party query-bus implementation would not?
• Is there any internal mandate (existing Symfony estate, shared library) creating real pull toward this pattern?

Integration Approach

Stack fit

Poor for a standard Laravel application. Viable only in one scenario: the team is already committed to Doctrine via laravel-doctrine and already standardizes on the UselessSoft query abstraction across services. Absent that, the cost/benefit is clearly negative — Eloquent plus dedicated query/action classes covers the same ground with zero third-party risk.

Migration path

If a decision is made to proceed, do not consume the package from Packagist as-is. Fork it into a controlled VCS namespace, vendor it via a Composer path or VCS repository, re-license explicitly after legal review, and add PHP/Doctrine version constraints yourself. Treat it as source code you now own, not a dependency you consume.

Compatibility

Must be verified empirically before any commitment: run a Composer why-not analysis against the current PHP and Doctrine versions, confirm the parent queries package resolves, and check for PHPUnit and static-analysis version conflicts in the dev constraints. Expect breakage at the Doctrine 3 boundary.

Sequencing

1. License and provenance review (blocking gate).
2. Evaluate the parent queries library health — if it is also dormant, stop here.
3. Time-boxed spike in a sandbox branch: one query object, one handler, one Doctrine-backed read path.
4. Compare against a first-party implementation of the same pattern (~1–2 days) as the build-vs-fork baseline.
5. Adopt only if the spike clearly beats the build baseline and a named owner accepts fork maintenance.

Operational Impact

Maintenance

You inherit 100% of it. The upstream is archived, so every future PHP major, Doctrine major, and security advisory becomes your ticket. Realistically this is a small file count, so the absolute effort is low — but it is permanent and it lands on whoever owns the persistence layer.

Support

None. No maintainer, no issue triage, no documentation beyond a README, no community to consult. Internal ramp-up depends entirely on the team reverse-engineering the parent library's conventions.

Scaling

Technically neutral. Query objects are short-lived and stateless; throughput is determined by Doctrine's unit-of-work, hydration strategy, and connection pooling, not by this adapter. No scaling concern originates here — but no scaling benefit does either.

Failure modes

• Silent breakage on a routine composer update when a transitive Doctrine constraint resolves to an incompatible version.
• Legal/compliance stop-work if license provenance cannot be established before a release or audit.
• Knowledge concentration: the one engineer who understands the query-bus convention leaves, and the pattern becomes unmaintainable legacy.
• Doctrine 3 migration blocked with no upstream path.

Ramp-up

Low code volume, but a steep conceptual ramp for an Eloquent-native team — they must learn Doctrine metadata, DQL, the unit of work, and the UselessSoft handler-resolution convention simultaneously. Budget 2–3 weeks before a mid-level Laravel engineer is productive.

Recommendation: Do not adopt. The functional surface is small enough to reimplement in-house in days, which eliminates the archived-dependency and license risk entirely. Revisit only if an existing Doctrine/query-bus estate makes the convention a hard constraint — and even then, vendor a fork with a named owner rather than depending on the published package.