Doctrine Cache Extension Laravel Package

Product Decisions This Supports

• Caching-layer architecture inside Doctrine-backed services. The package exists to add behavior on top of Doctrine Cache (driver variants, invalidation/namespacing, save-mode style controls — verify the exact surface in the README before relying on it). The real product decision it informs is: do we extend Doctrine Cache, or standardize caching on Illuminate\Cache (Laravel) / PSR-6 (symfony/cache)? For almost every roadmap item, the answer is the latter.
• Build vs. buy for cache plumbing. The capability is small enough that an in-house adapter behind your own CacheRepository interface is typically cheaper to own than a dependency. This is a "build" decision, not a "buy."
• Legacy modernization sequencing. If a service is still on Doctrine ORM/Cache 1.x, this feeds the decision to either (a) patch the existing stack for one more quarter, or (b) fund the migration to PSR-6 or Laravel's cache contract.
• Dependency-risk triage. With 0 dependents, no visible stars, and no maintenance signal, this belongs in the tech-debt/risk register as a liability line item, not in a platform strategy deck. It should not gate any feature commitment.
• Scope discipline. Separates "caching is a product capability" (worth an owner, SLIs, and invalidation design) from "caching is an implementation detail" (fine to swap out unilaterally).

When to Consider This Package

Consider only if all of the following hold:

• You are on a legacy Doctrine 1.x stack and need the specific extra behavior it provides, and you've confirmed a handful of lines of application code genuinely cannot replicate it.
• You accept it as unmaintained: pinned to an exact version, license verified, PHP constraint compatible with your runtime, and CI green on the pinned commit.
• It sits behind an interface you own, so replacing it never touches feature code.
• A named engineer owns it and a removal ticket already exists.

Look elsewhere when:

• You're on Laravel. Illuminate\Cache already gives you drivers, TTLs, tags, and atomic locks. Bridging Doctrine Cache into it adds surface area for zero product value.
• You're building new code or modernizing. doctrine/cache 2.x removed most of the legacy API; the ecosystem standardized on PSR-6 (symfony/cache, cache/chain-adapter, cache/array-adapter).
• You need support, security patching, or a vendor SLA. Zero dependents is a strong signal nobody will triage an issue.
• The need is just "cache this query result." A first-party cache repository or a Symfony/Laravel adapter does that with a maintainer behind it.

How to Pitch It (Stakeholders)

Executives (one paragraph): "This is a small, effectively unmaintained utility that adds caching behavior to an old database layer. It doesn't unlock a customer-facing capability and it isn't a platform bet — it's plumbing. My recommendation is not to adopt it for new work. If a legacy service already depends on it, we treat it as contained technical debt and fund a replace-don't-extend path rather than building roadmap commitments on top of it."

Engineering (one paragraph): "Doctrine Cache is a deprecated API — 2.x gutted the legacy surface, and the ecosystem moved to PSR-6 or Laravel's cache contract. This extension has near-zero adoption and no visible maintainer, so adopting it means we own it. If we need the behavior, we write a single adapter behind our own CacheRepository interface, unit-test it, and keep Doctrine types out of domain code — roughly half a day to a day, well under the cost of carrying an orphaned dependency. If a legacy app must keep it short-term, pin an exact version, add a Composer advisory/audit check to CI, and file a removal ticket with the migration to symfony/cache or Illuminate\Cache in the next cycle."