Read Models Bundle Laravel Package

Product Decisions This Supports

• CQRS / read-model adoption — whether to introduce denormalized projections alongside a write model instead of querying normalized tables directly. This package is the Symfony wiring for that pattern, so it only becomes relevant after the pattern decision, not as input to it.
• Build vs. buy on the integration layer — the bundle is thin DI/config glue over somnambulist/read-models. The honest comparison is "vendor the abstractions and wire them ourselves" versus "adopt this," and the build side is small. It should never be compared against a heavyweight CQRS platform.
• Framework strategy fit — this is a Symfony bundle, not a Laravel package. For a Laravel-first team this is effectively a decision against; the only carryover is the underlying library's plain-PHP interfaces.
• Roadmap gating — only worth a spike if there is a committed event-sourcing or projection-read initiative. Absent that, it is premature architecture with a maintenance tail.
• Vendor/risk register — an explicit "do not standardize on this" entry. One star, zero dependents, and a near-zero score mean no ecosystem signal, no regression surfacing, and no community support path.

When to Consider This Package

Consider it only when all of the following hold:

• The application is Symfony — the bundle delivers no value outside Symfony's container and config system.
• You have already selected somnambulist/read-models (or an equivalent abstraction) as your read-side contract.
• You are standardizing multiple read models and want consistent container registration instead of hand-wiring each one.
• You accept owning the code: fork or vendor it, pin the version, and budget maintenance time. Upstream has essentially no users to surface breakage.

Look elsewhere when:

• You are on Laravel — evaluate the underlying library's interfaces or a maintained CQRS package instead.
• You need a supported dependency with a security/response SLA; a single-star, zero-dependent bundle cannot supply one.
• Your read side is simple — a handful of projections is cheaper with plain query objects or repositories than with a new abstraction layer.
• You require a community-vetted, actively maintained component. The adoption numbers here are a disqualifier, not a hidden gem.

How to Pitch It (Stakeholders)

Executives: This is a small, unproven Symfony integration package supporting a specific architectural pattern — separating read models from write models for query performance. It is not a platform, not a Laravel component, and not something to standardize on. Near-zero adoption means no ecosystem safety net, so the downside is not licensing cost but maintenance ownership. Recommendation: treat it as a reference implementation only; if we pursue the pattern, the glue is cheap to replicate in-house.

Engineering: The bundle is thin dependency-injection glue over somnambulist/read-models. Read the source rather than adopting it as a dependency. If the pattern fits our domain, vendor the abstractions and wire them ourselves so we control upgrades and Symfony version compatibility. The real decision is the architecture — CQRS and projection-based reads — and this package should not be allowed to drive it.