Broadway Laravel Package

Product Decisions This Supports

• Architecture bet: CQRS/event sourcing vs. conventional CRUD. This package lowers the cost of trying event sourcing inside a Laravel codebase. That makes it useful for a time-boxed spike that informs a roadmap-level decision, rather than a decision you make blind.
• Build vs. buy (vs. fork) for eventing infrastructure. The package supplies infrastructure and testing helpers — aggregate/event plumbing and test utilities — that would otherwise be hand-rolled. MIT licensing means "buy" can degrade gracefully into "vendor and fork" if the upstream stalls.
• Audit, compliance, and temporal-query features. Event-sourced writes produce an append-only history. If the roadmap contains audit trails, "state as of date X" reporting, or replay-based debugging, an event log changes those features from bespoke engineering to queries over existing data.
• Use-case fit assessment. Best candidates are domains with complex state transitions and a need for history: order lifecycle and fulfillment, ledger/balance systems, reservations and inventory holds, approval workflows with compensating events. Poor candidates: simple CRUD screens, reporting-only workloads, teams under heavy delivery pressure.
• Testing and quality-gate strategy. The testing helpers are the most immediately defensible value: asserting aggregate behavior and projection correctness is where event-sourced codebases usually rot. This supports decisions about definition-of-done and CI coverage for the evented bounded context.
• Blast-radius engineering. Because the package is small and isolated, it supports a roadmap decision to keep event sourcing confined to one bounded context behind an interface — making the eventual swap to another library a refactor, not a rewrite.
• Hiring and onboarding planning. Event sourcing shifts the skill profile (aggregates, idempotency, eventual consistency, projection rebuilds). Adopting a package is also a decision to invest in team fluency.

When to Consider This Package

Consider it when:

• You are on Laravel/PHP and have a specific, named use case requiring history, replay, or temporal queries — not a general "we should be more event-driven" impulse.
• You primarily want the testing helpers to validate aggregates and projections during a spike or a pilot bounded context.
• You can vendor or fork the code and accept ownership: pin the commit, review the source, and treat it as internal infrastructure.
• The integration is non-critical path — internal tooling, a pilot service, or a proof of concept with a defined exit criterion.
• Your team has, or is deliberately building, event-sourcing literacy and can evaluate the abstractions rather than inherit them.

Look elsewhere when:

• Traction and maintenance signals matter. Zero stars, zero dependents, and no release since July 2023 mean no community, no documented security response, and no one to escalate to. For anything on a revenue or compliance path, that is disqualifying on its own.
• You need production support, SLAs, or a hiring pool — none exist here.
• You need documentation and worked examples to onboard engineers; a package this small and this quiet will not teach the patterns.
• You need mature projection rebuilds, snapshots, event-store adapters, or upcasting beyond what's included — evaluate broadway/broadway (the upstream lineage this appears to derive from), spatie/laravel-event-sourcing for Laravel-native ergonomics, event-sauce/event-sauce, or prooph for a broader ecosystem.
• The domain is simple CRUD or read-heavy reporting. Event sourcing adds operational cost — eventual consistency, replay tooling, schema evolution — that your product does not earn back.
• You cannot absorb the cognitive load: eventual consistency surprises, idempotent handlers, versioned events, and projection lag are product-visible behaviors, not just code concerns.

How to Pitch It (Stakeholders)

To executives: This is a low-cost option to evaluate, not a platform commitment. It gives us a cheap way to test whether event sourcing fits a specific part of the product — the kind of architecture that makes audit history, "what did this look like last month," and safe replay of past states into built-in capabilities rather than new projects. The tradeoff is honest: the package is a solo, unmaintained open-source project with no user base, so we would own the code if we used it. The ask is a time-boxed spike with a go/no-go gate, not adoption. If the spike succeeds, we either fork and maintain a small surface area internally or migrate to a better-supported library — the cost of switching at that point is measured in days, because we would keep it behind one boundary.

To engineering: It's a thin infrastructure-plus-testing-helpers layer for CQRS and event-sourced apps on Laravel, MIT-licensed, small enough to read end to end in an afternoon. The testing utilities are the real draw — they make aggregate and projection assertions cheap, which is where these designs usually degrade. The risks are equally concrete: last release July 2023, no dependents, no community, unknown maintainer bandwidth. So the proposal is to vendor it, pin it, and treat it as our code from day one. If the spike validates the patterns, we make a deliberate choice between owning the fork, moving to spatie/laravel-event-sourcing for Laravel-native alignment, or reverting to CRUD with an explicit audit table. Success criteria: one bounded context, projection rebuild in a test, and a clear answer on operational cost — before anything touches a production path.