Read Models Bundle Laravel Package

Technical Evaluation

Architecture fit — critical mismatch. The brief frames this as a Laravel/PHP package, but somnambulist/read-models-bundle is explicitly a Symfony bundle. It contains no Laravel service provider, no facade, no config publishing, and no illuminate/* contracts. On a Laravel codebase it is not installable-to-purpose: Flex auto-registration is meaningless, the DependencyInjection/*Extension and compiler passes never run, and you would be pulling a dead dependency. If the team is on Laravel, the only reusable artifact is the underlying framework-agnostic library (somnambulist/read-models), which would need hand-written container bindings. If the team is on Symfony, the bundle is architecturally appropriate: it is a thin DI/config glue layer that registers read-model repositories, projection wiring, and storage adapters as services.

Integration feasibility. Mechanically trivial where it applies — a single composer require plus bundle registration, with configuration surfaced under a bundle alias. The real gating factor is the version constraint matrix. With 1 star and 0 dependents there is effectively zero community validation of compatibility against current Symfony releases, current PHP minors, or the projection-store backends (PDO/Doctrine/Redis). You must read composer.json constraints directly and expect to widen or pin them yourself. The library it wraps is the substantive dependency; the bundle is a few hundred lines at most.

Technical risk. Three distinct risks, in order of severity:

1. Adoption signal is near-noise. 1 star, 0 dependents, composite score 0.005 means no independent production evidence, no issue backlog to mine for failure modes, and no passive regression testing by third parties.
2. Bus factor of one. Single-maintainer ecosystem (somnambulist-tech). Both the library and the bundle share that exposure; the bundle is the smaller risk because its surface is small and forkable.
3. Pattern risk exceeds package risk. Read models imply CQRS/projection discipline: eventual consistency, rebuild strategies, idempotency. Adopting the bundle without that architectural commitment produces a worse outcome than not adopting it.

Key questions to resolve before any decision:

• Which framework are we actually standardizing on — Symfony or Laravel? (This alone determines whether the package is in scope.)
• Do we already run event sourcing or CQRS anywhere, or is this greenfield pattern introduction?
• What projection store do we need, and does the wrapped library support it at the version we'd pin?
• What is our policy on single-maintainer dependencies — vendor, fork, or reject?
• Is the underlying somnambulist/read-models library itself under active release, or is the bundle packaging a dormant project?

Integration Approach

Stack fit. If Laravel: do not integrate this bundle. Either (a) skip read models entirely, (b) use an in-house projection layer over existing Eloquent/query-builder infrastructure, or (c) adopt somnambulist/read-models directly and write ~50–100 lines of service-provider bindings — which is strictly cheaper than adapting a Symfony bundle and removes a dependency. If Symfony: the bundle is the intended integration path and fits Flex conventions with no ceremony.

Migration path. There is no migration — this is greenfield adoption, not a replacement. If the underlying library is chosen on a Laravel stack, the path is: library only → hand-rolled bindings → optionally upstream a Laravel provider later. If Symfony, adopt the bundle from day one; there is no benefit to using the library bare and adding the bundle afterward, though it is possible.

Compatibility. Verify three axes explicitly before committing: PHP version constraint against our runtime floor, Symfony component constraint against our LTS/minor, and the projection-store adapter. Expect to fork and patch constraints; budget for it. For Laravel, the compatibility question is inverted — nothing will match because nothing is designed to.

Sequencing.

1. Confirm framework of record (blocking).
2. Spike the library in one bounded context with one read model and one projection, rebuilt from scratch on demand. This validates the pattern, not the bundle.
3. Only if the spike succeeds, formalize DI wiring — bundle on Symfony, in-house bindings on Laravel.
4. Extract a repeatable projection-rebuild runbook before onboarding a second context.
5. Defer any wider rollout until at least two contexts are running and rebuilds are boring.

Operational Impact

Maintenance. Assume we own this code. At 1 star and 0 dependents, upstream is a courtesy, not a support channel. Plan to vendor or fork on first incompatibility — the bundle's small surface makes this tractable, but the wrapped library's surface is not small, and that is where maintenance cost concentrates. Track upstream releases manually; there is no ecosystem pressure to keep it current.

Support. No community, no Stack Overflow corpus, no third-party tutorials, no issue history to search. Internal documentation must be written by us from the source. Expect onboarding to be source-reading rather than doc-reading.

Scaling. The bundle itself is a configuration-time artifact with negligible runtime cost — it is not the scaling unit. Scaling is determined entirely by projection store throughput, rebuild duration, and event volume. Flag that projection rebuild time becomes an operational ceiling: if a full rebuild takes hours, schema changes to read models become change-management events.

Failure modes.

• Abandonment/version drift — highest likelihood. A PHP or Symfony major bump breaks constraints with no upstream fix.
• Silent DI misconfiguration — services registered but tags or aliases wrong; failures surface as missing-service errors at runtime, not at boot, depending on container compilation.
• Projection staleness — read models diverge from the write model with no built-in reconciliation; this is an application-design failure mode the bundle does not protect against.
• Rebuild failure mid-stream — partial projection state requiring idempotent replay discipline we must design ourselves.
• False-positive adoption — a developer installs it on Laravel, sees no error at install time, and discovers the mismatch at first container resolution.

Ramp-up. The bundle itself is a half-day of reading. The pattern is the cost: engineers need working literacy in CQRS, projection lifecycle, eventual consistency, and idempotent handlers before the package is useful. Budget 1–2 weeks of ramp-up per engineer for the concepts, and do not count the package's low line count as low onboarding effort — it is a thin wrapper around a conceptually heavy model.

Recommendation. Do not adopt on the stated basis. The framework mismatch is disqualifying for a Laravel codebase, and the adoption signal (1 star, 0 dependents, 0.005 score) does not justify carrying a single-maintainer Symfony-specific dependency on a Symfony codebase either — the same wiring can be written in-house in under a day if the underlying library is genuinely wanted. Revisit only if the underlying somnambulist/read-models library is independently selected on architectural merit, in which case the bundle is a convenience, not a decision.