Product Decisions This Supports
- Architecture direction: event-sourced vs. CRUD. This package exists to make a bounded context's write model event-sourced and its read model query-optimised. Adopting it is the moment a product commits to CQRS/ES for a domain rather than layering it on later — a one-way door for that context, so it belongs in an ADR, not a sprint ticket.
- Build vs. buy for domain scaffolding. It supplies interfaces and a few base classes — the seams (command bus, aggregates, event store, projections) rather than a full framework. That makes the build-vs-buy answer "buy the contracts, build the domain": you get a stable vocabulary for free and keep the interesting logic in-house.
- Feature justification: auditability, temporal queries, replayability. Products that need "what did this record look like on 3 March?", regulator-grade audit trails, or the ability to backfill a new read model by replaying history are exactly the features this unlocks cheaply. If the roadmap has none of those, the package earns nothing.
- Use-case fit. Strongest for transactional domains with a natural event vocabulary: ledgers, scoring/ranking engines, bookings, inventory movements, workflow approvals. Weak for reporting-first or content-heavy products where state is mostly overwritten and history is noise.
- Roadmap sequencing. Since the package is interface-only, adoption is a low-cost spike: prototype one bounded context behind the interfaces, measure the cost of the read-model and migration work, and let that estimate — not the package's pitch — drive whether event sourcing spreads to other contexts.
When to Consider This Package
Consider it when:
- The team already understands aggregates, events, and eventual consistency; the package's interfaces map onto concepts you'd otherwise write yourself.
- You want the shape of CQRS/ES without a heavyweight framework's opinions, runtime, or upgrade treadmill — swapping a thin interface layer later is cheap; swapping a framework is not.
- The domain is genuinely event-shaped and the business will tolerate read-model lag in exchange for a trustworthy history.
- You are prototyping and want a disposable spike to price the real work before committing.
Look elsewhere (or write it yourself) when:
- Maturity matters. Zero stars, zero dependents, no release history, and a single maintainer on a self-hosted GitLab make this a bus-factor-of-one dependency. For anything revenue-critical, prefer a maintained alternative (EventSauce, Broadway, Prooph) or build the few interfaces in-house — they are small.
- You need Laravel-native ergonomics. Despite the PHP/Laravel framing, this is not a Laravel package with service providers, Eloquent persistence, or queue integration. If you want batteries included, use a dedicated Laravel event-sourcing package.
- You need documentation, support, or a community. There is effectively none verifiable here. Budget for reading source and writing your own guides.
- You lack team experience with ES. The failure mode isn't the library, it's the modelling. Without an experienced hand, event sourcing increases delivery cost and operational risk regardless of which package you pick.
- Regulated or long-lived procurement. Unverifiable maintenance status will fail most vendor-risk reviews; plan the in-house-subset fallback up front.
How to Pitch It (Stakeholders)
To executives: This is a small, free PHP library of interfaces for a well-established architecture pattern (CQRS and event sourcing — keeping a complete, replayable history of what happened rather than only the current state). Because it contains contracts rather than a heavy framework, we can trial it in one bounded area at very low cost and reverse the decision if it disappoints. It is not a platform bet: no licence fee, no lock-in, no data migration. What it buys us is the option to answer questions like "what did this look like last quarter and why" without bespoke audit plumbing — valuable if our roadmap leans toward compliance, disputes, or financial-grade records. Caveat: it is a one-maintainer project with no visible community, so I recommend it only as a spike or for internal tooling until we've proven the pattern; we should assume we may need to own the code.
To engineering: Think of this as a vocabulary, not a framework. It gives us interfaces for the command side, aggregates, and event storage, plus a few base classes — deliberately unopinionated, so persistence, transport, and projections stay ours. Upside: the abstractions are thin enough that replacing them with our own is days, not months, and there's no runtime baggage. Downside: zero stars, zero dependents, single maintainer, no docs — treat every module as unvetted source until read. Proposal: timeboxed spike in one context, wrap every import behind our own port so the dependency stays at arm's length, and make the go/no-go call on measured read-model and migration effort rather than on the package's merits. If the spike doesn't clearly beat hand-rolling roughly a dozen interfaces, we hand-roll.