Broadway Bundle Laravel Package

Product Decisions This Supports

• Architecture direction: event sourcing vs. CRUD. If the roadmap includes an audit trail, temporal queries ("what did this order look like on March 3rd?"), or replayable domain history, Broadway is one of the few mature PHP implementations of CQRS + event sourcing. This package is only the Symfony wiring — the real capability lives in broadway/broadway.
• Build vs. buy for event infrastructure. Informs whether the team hand-rolls an event store (aggregate persistence, projections, sagas) or adopts an existing library. Hand-rolling is 4–8 weeks of engineering plus ongoing maintenance; a library is a dependency bet.
• Feature-level: regulated or audit-heavy domains. Payments, invoicing, inventory, healthcare workflows — where "why is this record in this state?" is a product requirement, not an engineering nicety.
• Integration strategy. Event sourcing naturally produces a domain event stream, which supports decisions about webhooks, third-party sync, and read-model/denormalization strategy for performance-sensitive screens.
• Team capability investment. Adopting this drives a decision to fund DDD/CQRS training, since event sourcing changes how engineers model features — a people/roadmap cost, not just a library choice.

When to Consider This Package

Consider the underlying Broadway library only if all of the following hold:

• The application is Symfony, not Laravel. This package is a Symfony bundle — for a Laravel codebase it is effectively unusable without custom integration work.
• The team already understands aggregates, projections, and eventual consistency, or is prepared to invest in that learning curve.
• You need true event sourcing, not just an audit log (a simple activity_log table or database triggers solve the audit-log case at a fraction of the cost).

Do not adopt this package specifically, and look elsewhere if any of these are true:

• Maintenance risk is unacceptable. 0 stars, 0 dependents, last release August 2019, and no visible adoption. There is no community to catch bugs and no evident maintenance commitment. Treat it as unmaintained glue code.
• You are on Laravel. Use spatie/laravel-event-sourcing instead — it is actively maintained and idiomatic.
• You are on modern Symfony (5.4+/6.x/7.x) or PHP 8.1+. Use patchlevel/event-sourcing or ecotone/cqrs for a maintained, actively developed event-sourcing layer.
• You only need CQRS read/write separation, not event sourcing. A plain service/repository split is cheaper and reversible.
• Your domain is simple. Event sourcing adds schema-migration-on-event-change pain that rarely pays off for straightforward CRUD products.

Practical recommendation: if event sourcing is genuinely on the roadmap, run a 1–2 week spike with patchlevel/event-sourcing (Symfony) or spatie/laravel-event-sourcing (Laravel) on a single bounded context. Do not let this bundle's existence be the justification for the architecture decision.

How to Pitch It (Stakeholders)

For executives: There is an open-source PHP library for event sourcing — storing every state change as an immutable event rather than just the current row. That capability supports audit trails, "time travel" debugging, and clean integrations. However, the specific package evaluated here (macnificos/broadway-bundle) is a thin, unmaintained Symfony wrapper with zero adoption (0 stars, 0 dependents, last release 2019). Recommendation: do not adopt this package. It carries supply-chain and maintenance risk with no offsetting benefit.

For engineering: The value is in broadway/broadway, not this bundle. If we pursue event sourcing, pick a maintained implementation — patchlevel/event-sourcing for Symfony, spatie/laravel-event-sourcing for Laravel — and scope it to one bounded context as a pilot. Budget for upskilling: event sourcing changes modeling, testing, and deployment (projection rebuilds, schema versioning), and it is expensive to reverse once features depend on it.

Bottom line: the architectural question (do we event-source anything?) is worth a decision; the package question is a clear no. Treat this bundle as a signal that the ecosystem exists, not as a candidate dependency.