Broadway Bundle Laravel Package

Product Decisions This Supports

• Feature architecture: event sourcing vs. CRUD. Broadway is a CQRS + Event Sourcing library. This bundle wires it into a Symfony app (command/event buses, event store, read-model projections). It supports the decision to model a domain as an append-only event log — relevant for ledgers, order lifecycles, payments, inventory, and any workflow where "what happened and when" is a first-class product requirement.
• Compliance / auditability roadmap. If a roadmap item is "traceable history of every state change" or "replay to reproduce a customer's account at any point in time," event sourcing is the native answer. This package is the Symfony glue that makes that tractable rather than a bespoke build.
• Build vs. buy (glue vs. core). broadway/broadway is the substantive upstream; this bundle is thin integration/config plumbing. That reframes the decision: you are not buying a system, you are buying a wiring convention. Default to evaluating Broadway itself and treating this bundle as optional convenience — writing your own service definitions is a legitimate, low-cost alternative.
• Use cases to prototype: event replay for debugging, temporal queries, projections for read-optimized dashboards, outbox/event publishing for downstream services.
• Explicitly does not support: CRUD apps, simple admin tooling, teams without prior CQRS/ES experience, Laravel-based products (see below). Adoption of this package is a statement that the domain warrants event sourcing — a significant architectural and hiring commitment, not a library pick.

When to Consider This Package

Consider it when:

• The stack is Symfony, not Laravel. This is a Symfony bundle; it will not drop into Laravel without custom integration. If the product is Laravel-first, the correct framing is "evaluate broadway/broadway directly plus a hand-rolled service provider," not this package.
• You have already made the architectural call to use Broadway and want to reduce boilerplate for bus/event-store wiring.
• The domain has genuine event-sourcing fit: strong audit requirements, complex state transitions, need for temporal reconstruction.
• You have senior PHP engineers fluent in DDD/CQRS and can absorb the maintenance burden of glue code yourselves if the package stalls.

Look elsewhere when:

• Community and maintenance signals are the deciding factor. Zero stars, zero dependents, and a last release in July 2023 are weak validation. For a component that sits on your write path, that is a material risk. Expect to fork and own it.
• You need a maintained, documented ecosystem. Prefer event-sauce/event-sauce, patchlevel/event-sourcing (well-maintained, Laravel/Symfony friendly), ecotone, or spatie/laravel-event-sourcing (if Laravel) — several of which have real user bases and active releases.
• A plain audit log, append-only history table, or spatie/laravel-activitylog-style solution satisfies the requirement. Event sourcing carries real operational cost (projection rebuilds, versioning, eventual consistency) that is rarely justified by "we want history."
• Your team lacks ES experience and the timeline doesn't allow a learning curve. The failure mode is a half-implemented event store that's harder to unwind than a monolith.
• Vendor/security review requires active maintenance guarantees — this fails that bar.

Adoption gate: pilot in a bounded, non-critical domain (one aggregate, one projection) before any roadmap commitment. Confirm you can rebuild projections and version events without touching this bundle's code.

How to Pitch It (Stakeholders)

For executives (one line): Broadway is a proven pattern for systems that must remember every change — it gives us audit-grade history and the ability to reconstruct state at any point in time. This particular package is thin Symfony plumbing around it, so the real decision is whether our domain needs event sourcing, not whether we adopt this bundle.

• Frame the value as risk reduction and traceability, not features: defensible audit trails, reproducible incident forensics, and a foundation for event-driven integration with other systems.
• Be explicit about cost: higher design rigor, projection infrastructure, team training. It pays off in domains with real state complexity and regulatory scrutiny; it is overkill elsewhere.
• Flag the dependency risk honestly: near-zero community adoption and a 2023 release mean we should plan to own the integration. Position this as an internal capability investment with broadway/broadway (the maintained core) as the durable asset, and the bundle as replaceable.
• Recommend a bounded pilot with a go/no-go checkpoint, and set the expectation that a "no" is a valid, cheap outcome.

For engineering: Treat this as glue, not a platform. Evaluate Broadway core first; if the bundle saves less than a day of wiring, skip it. Budget for projection rebuild tooling, event versioning/upcasting, and schema-migration discipline on the event store — those, not this package, determine success.