Laravel Eventsauce Laravel Package

Product Decisions This Supports

• Build vs. buy on event infrastructure. This package is a thin adapter, not an event store. It lets us use EventSauce (the mature, framework-agnostic event sourcing library) inside Laravel's service container, queue, and config conventions. The real "buy" decision is EventSauce; this package is the glue that avoids us writing our own service provider, message dispatcher wiring, and aggregate persistence bindings. Release 0.5.0 reinforces that framing: the adapter now tracks EventSauce 1.x, so the dependency we lean on is the library's stable major, not a frozen 0.x snapshot.
• Adopting event sourcing for a bounded context. Choosing this package signals a commitment to aggregates, domain events, and a persisted event log — which unlocks audit trails, temporal queries ("what did this record look like on date X"), and rebuilding read models from history. That is a product capability decision, not just a technical one; it should be scoped to one context (e.g., payments, orders, compliance-sensitive workflows), not applied platform-wide.
• Roadmap sequencing for audit/compliance features. If the roadmap contains regulator-facing history, dispute reconstruction, or "explain why this state changed," event sourcing via EventSauce is a credible path, and this package is the shortest route to a working Laravel spike.
• CQRS and read-model strategy. The integration supports separating write-side aggregates from read-side projections, which affects how we staff and sequence work: projections and replay tooling become their own backlog items, not incidental work.
• Architecture spike / proof-of-concept funding. Adoption is still thin (low star count, ~0 dependents, a long gap before this release), so the responsible decision this package supports remains funding a time-boxed spike, not a production commitment — specifically to test Laravel-version compatibility, validate the 0.4 → 0.5 upgrade path, and estimate our own maintenance burden.
• Team capability investment. Event sourcing shifts debugging, migration, and schema-evolution work onto the team. This decision should be made with an explicit estimate of onboarding cost, not treated as a library swap.

When to Consider This Package

Adopt (or, more precisely, trial) it when:

• Event sourcing is already the decided direction and EventSauce is the chosen library — this package is the natural Laravel seam and saves bespoke wiring.
• You target EventSauce 1.x. Version 0.5.0 exists specifically to align the adapter with EventSauce 1.x. Greenfield work should start here; anything still on 0.4.0/EventSauce 0.x faces a coordinated upgrade of both layers.
• You have verified Laravel compatibility yourself. The 0.5.0 changelog covers only the EventSauce upgrade — it says nothing about framework support. Run the test suite against our target Laravel version before estimating; a single dependency bump does not establish compatibility with newer Laravel majors.
• The team accepts ownership. Treat it as vendored/forked code from day one: pin the version, fork it internally, and budget for maintaining the service provider against future Laravel releases. The MIT license makes this straightforward.
• The scope is one bounded context where audit history and replayability carry real product value, and where the domain has genuine invariants worth modeling as aggregates.
• You have a spike-sized window to validate persistence, queue integration, and projection replay before committing the roadmap.

Look elsewhere — or do not proceed — when:

• You need evidence of sustained maintenance. One release after a multi-year gap is a data point, not a trend. There is still no community safety net and no track record of responsiveness to Laravel breaking changes. This remains the dominant risk.
• You are on the latest Laravel. Framework majors move fast; expect the service provider and config publishing to need work. Verify before estimating.
• You have existing event streams on EventSauce 0.x. The 1.x upgrade is a breaking change at the library level; treat serialization/upcasting compatibility for historical events as a real migration workstream, not a composer bump.
• You only need an audit log. An append-only audit table, or Laravel's own model history approaches, delivers most of the compliance value at a fraction of the operational cost. Event sourcing is a poor fit for "we just need a change history."
• The domain is mostly CRUD. Aggregates and events add ceremony with little payoff where there are few invariants and no replay requirement.
• You want a managed or vendor-supported event platform. This is a community glue package with no support contract; if the organization requires SLAs, evaluate commercial event stores instead.
• No one on the team has event sourcing experience and there is no budget to acquire it. The library is not the hard part; the modeling discipline is.

How to Pitch It (Stakeholders)

For executives: Event sourcing gives us a permanent, replayable record of every business state change — a strong foundation for audit, compliance, dispute resolution, and analytics, and one we cannot retrofit cheaply later. EventSauce is a credible, MIT-licensed PHP library for this, and its own author has now stepped in to bring the Laravel adapter up to EventSauce's stable 1.x line. That is a genuine positive signal, but it is one release, not a maintenance commitment: adoption is still near zero and we should assume we own the adapter. So the recommendation is unchanged — not "adopt," but "invest one spike to validate, then decide." Cost is bounded, the downside is a short spike, and the upside is an architecture that de-risks compliance features on the roadmap.

For engineering: This is a thin integration layer — service provider, config, message dispatching, aggregate bindings — between Laravel and EventSauce. Release 0.5.0 is a single change: upgrade to EventSauce 1.x, contributed by frankdejonge (EventSauce's maintainer), which is why it's worth taking seriously despite the project's quiet history. Two consequences: (1) it's a breaking upgrade for anyone on 0.4.0/EventSauce 0.x, so plan event serialization and upcasting for existing streams; (2) the release notes say nothing about Laravel version support, so re-run the suite against our target framework before promising anything. Treat it as vendored code: pin 0.5.0, fork, own it, add a compatibility test. The real design work remains aggregate boundaries, event schema evolution, and projection replay tooling — plan and staff for those explicitly, and scope to a single bounded context first.

Bottom line: the maintenance risk is marginally better, not resolved. Upgrade the spike to evaluate 0.5.0 + EventSauce 1.x specifically; keep the fork-and-own decision and a Laravel compatibility proof as gates before any roadmap commitment.