Event Store Bus Bridge Laravel Package

Product Decisions This Supports

• Architecture choice: CQRS + Event Sourcing for a bounded context. This bridge is the glue between a prooph event store and a command/query bus — it lets write-side commands persist domain events and lets read-side projections subscribe to them. The product decision it supports is "do we adopt event sourcing for this domain," not the bridge itself.
• Roadmap capabilities that justify ES:
  • Permanent, replayable audit log of every state change (compliance, dispute resolution, "who changed what when").
  • Temporal queries ("show state as of date X") without building parallel history tables.
  • Adding new read models / reports by replaying events instead of backfilling with migrations.
  • Safer recovery from projection bugs — rebuild reads from the event log.
• Build vs. buy: hand-rolling the bus↔event-store wiring is small but easy to get subtly wrong (transaction boundaries, dispatch semantics, failure handling). Using the package is the "buy" side — but it is a secondary decision behind the choice of the prooph stack itself, which is where the real cost and risk sit.
• Use cases: high-behavior-density domains — order management, ledgers/payments, inventory, regulatory workflows — where invariants are complex and history matters. Poor fit for CRUD-heavy admin apps where a simple audit-log package achieves the same product outcome for a fraction of the cost.
• Cost/benefit framing: ES raises upfront engineering cost and requires senior engineers, but lowers long-term schema-migration and reporting-change cost.

When to Consider This Package

Consider it when:

• You have already committed to prooph/event-store (v7-era) and prooph/service-bus, and need standard glue rather than a custom adapter.
• A specific bounded context genuinely warrants event sourcing (audit, temporal queries, complex invariants) — not merely "we want events."
• You have verified compatibility with your runtime. Last release 2021-08-26 and 37 stars suggest the package is pinned to older PHP versions; validate against PHP 8.2+/Laravel 10/11 before any commitment, and be prepared to fork/patch.
• Your team has CQRS/ES experience or budget to acquire it. The bridge is not a learning aid.
• You accept a low bus factor and no vendor support (repository status is unverified/unknown).

Look elsewhere when:

• It's a greenfield Laravel project. Prefer maintained, Laravel-native options: spatie/laravel-event-sourcing, EventSauce (with an outbox), Broadway, or event-engine (prooph's successor lineage).
• Your actual need is audit logging — use an activity-log package; don't adopt CQRS/ES for that alone unless you're comfortable owning the pattern's operational cost.
• Your need is asynchronous work — Laravel queues and events likely suffice; prooph's bus is an abstraction layer with ongoing cost.
• You require SLAs, long-term maintenance guarantees, or PHP 8.2+/Laravel 11 support with no appetite for forking.
• You need documentation and community answers — 37 stars means you'll be debugging largely on your own.

How to Pitch It (Stakeholders)

Executive summary

• What it is: a small integration package that connects an event store to a command/query bus — the plumbing that makes CQRS + Event Sourcing practical in PHP. It is framework-agnostic (usable in Laravel via a service provider), not a Laravel-native library.
• Business value it enables: a permanent, replayable history of every business change; strong audit and compliance story; new reports and read models built by replaying history rather than risky data migrations; clean separation of writes from reads.
• Cost: real and mostly not in this package. Event sourcing increases delivery cost and demands experienced engineers. The bridge is a few classes of glue; the pattern is the investment.
• Risk: low activity — 37 stars, last release August 2021, repository status unverified. Treat it as a maintenance liability in a modern Laravel codebase. Do not let a 37-star dependency anchor an architecture.
• Engineering pitch: if we've chosen prooph, use the bridge instead of re-implementing bus/event-store glue. If we're greenfield on Laravel, evaluate spatie/laravel-event-sourcing or EventSauce first — same product benefits (audit, replay, projections) with lower integration and maintenance risk.
• Recommendation: do not start new initiatives on this package unless we are already on prooph and have verified PHP/Laravel compatibility. For new work, select a maintained event-sourcing library and revisit prooph only if a concrete constraint — existing code, team expertise, or a specific integration — justifies it.