Read Models Laravel Package

Product Decisions This Supports

• Read/write split (lite CQRS): Lets you carve the query side of your domain into dedicated, typed read classes without adopting a full CQRS framework or event sourcing. The decision this unlocks is "do we introduce read models on the query path?" — and the package makes the cost of trying low.
• Build vs. buy for the query layer: The realistic alternative is hand-rolled DB::table() + array returns, or full Eloquent models reused for reporting. This package is the middle option: typed read objects with minimal ceremony, so a PM can defer investing engineering time in a bespoke abstraction.
• Feature delivery for data-heavy screens: Dashboards, list/table views, exports, and denormalized read paths can be built against purpose-built read models instead of stretching write-side Eloquent models with scopes and eager-loading hacks. Roadmap items that are "mostly display" become cheaper to scope.
• Performance and coupling trade-offs: Read models let the query shape evolve independently of domain entities and migrations. That is a product decision about how much coupling you accept between reporting and transactional schema.
• Use cases it fits: reporting endpoints, search/list APIs, admin panels, denormalized projections, and anywhere a controller currently does ad-hoc DB::table() work that nobody owns.

When to Consider This Package

Consider it when:

• You are on Laravel/PHP and already have raw query or Eloquent-scope sprawl on the read side that you want to type and isolate.
• You want read models without committing to a CQRS/event-sourcing stack, and without a new migration or ORM layer — this is deliberately "stripped down."
• Your team is small and would rather adopt a 200-line-style abstraction than design one; MIT license removes licensing friction.
• The feature is internal or non-critical: dashboards, back-office tooling, reporting where a small dependency is acceptable risk.

Look elsewhere when:

• Adoption signals matter. 12 stars, 0 dependents, single-maintainer, and a last release in March 2024. That is a real bus-factor and abandonment risk. For a core, long-lived domain layer, prefer Eloquent, Doctrine, or a first-party abstraction your team controls.
• You need write support, migrations, relationships, or an ecosystem — the package intentionally does not provide these.
• You need security-sensitive or high-traffic paths with guaranteed support, SLAs, or a large community to validate edge cases.
• The team already has a query-object or repository convention; introducing a second read convention adds inconsistency for little gain.

How to Pitch It (Stakeholders)

To executives: This is a small, MIT-licensed utility that lets engineers build fast, read-only data views (dashboards, reports, listings) without heavy framework work. It reduces delivery time on reporting-style features and avoids locking us into a big CQRS investment. Risk is contained because it sits on the read path only — nothing transactional depends on it — and it can be swapped out for a thin in-house class later. Recommendation: pilot it on one internal, non-critical reporting surface, not on core domain code.

To engineering: It is a minimal active-record-style query layer for fetch-only reads. It gives you named read classes with explicit table and column definitions, returning typed results instead of ad-hoc arrays — a clean seam between controllers and the database. It is not an ORM and does not handle writes or migrations, so it composes with existing Eloquent rather than replacing it. Caveat to state plainly: single maintainer, low adoption, last tagged release March 2024; treat it as a pattern-with-a-package, keep it behind a small internal interface, and be ready to fork or reimplement if it stalls.