Broadway Bundle Laravel Package

Technical Evaluation

Architecture fit: This is a Symfony bundle, not a Laravel package. Broadway (broadway/broadway) is a CQRS/Event Sourcing library, and this package exists to auto-wire Broadway services through the Symfony DI container via compiler passes and bundle configuration. Laravel has no bundle system — it uses service providers and its own container. That means the core value of this package (Symfony auto-configuration) is exactly the part that does not transfer to a Laravel stack. The underlying domain library is stack-agnostic; the bundle wrapper is not.

Integration feasibility: Low as-shipped. Adopting this in Laravel would require either (a) skipping the bundle entirely and wiring broadway/broadway manually inside a Laravel service provider, or (b) porting the bundle's compiler passes and config schema into Laravel equivalents. Neither is a drop-in. There is no Laravel bridge or adapter in the ecosystem (0 dependents confirms this).

Technical risk: High on several axes. Zero stars, zero dependents, and a last release of 2023-07-24 mean effectively no community validation and no evidence of ongoing maintenance. The dependency surface (symfony/* version ranges, Doctrine DBAL event store, Broadway's own release cadence) creates version-drift risk against modern Laravel (10/11/12), which pins its own Symfony component versions. A single-maintainer package with no downstream consumers is a supply-chain and longevity concern.

Key questions:

• Do we actually need CQRS/Event Sourcing, or is this architecture being adopted for its own sake? ES is a large commitment with poor fit for CRUD-shaped domains.
• Which Symfony major versions does the bundle declare, and do those overlap with the Symfony components Laravel currently ships?
• What is the event store backend (Doctrine DBAL? custom?), and does it require a second connection/database outside Laravel's Eloquent?
• Who owns this package upstream, and is there a maintenance commitment past the 2023 release?
• Are there alternative Laravel-native ES/CQRS options (e.g., spatie/laravel-event-sourcing, ecotone) that avoid the Symfony/Laravel impedance mismatch entirely?

Integration Approach

Stack fit: Poor as a direct dependency. The idea (Broadway in a PHP app) fits; this artifact (a Symfony bundle) does not. If Broadway specifically is mandated, consume broadway/broadway directly and treat this bundle as a reference implementation for wiring, not a runtime dependency.

Migration path: Do not composer require this into a Laravel app expecting it to work. Instead:

1. Write a BroadwayServiceProvider that registers EventBus, CommandBus, EventStore, and the read-model/projection services explicitly in Laravel's container.
2. If the bundle's compiler passes encode meaningful defaults, port those registration rules by hand — they are the only reusable knowledge here.
3. Keep the bundle in a dev/reference capacity only, if at all.

Compatibility: Confirm the composer.json constraints against the target Laravel version's Symfony component set before anything else. A 2023 bundle is unlikely to declare Symfony 7 support cleanly, and Laravel's locked component versions will fight it.

Sequencing:

1. Architecture decision: confirm ES/CQRS is justified for the domain (this gates everything).
2. Spike: wire broadway/broadway + a Doctrine DBAL event store inside a throwaway Laravel app — validate the container wiring, event dispatch, and projection replay end-to-end.
3. Only if the spike succeeds, decide whether to fork the bundle's config/compiler-pass logic as a Laravel-native package or abandon it.
4. Roll out behind a single bounded context first — never across the whole application.

Operational Impact

Maintenance: Effectively unmaintained. Last release mid-2023, zero dependents, zero stars — no signal of active stewardship. Any adoption means we own the code path; plan to vendor/fork under MIT rather than depend on upstream fixes.

Support: No community, no issue ecosystem, no Stack Overflow corpus. Support cost is internal-only and front-loaded onto whichever engineer learns the wiring. MIT license at least makes forking legally trivial.

Scaling: Scaling characteristics belong to Broadway and the event store, not this bundle — but the bundle's Symfony-Messenger-oriented assumptions (async consumers via Symfony Messenger) do not map to Laravel's queue system. Projection/read-model workers will need bespoke queue integration, and event-store throughput will be bounded by the underlying DB. Expect to design the async/worker layer ourselves.

Failure modes:

• Silent misconfiguration: Symfony compiler passes that fail to run in Laravel produce missing services rather than errors — events may simply never dispatch, and this is discovered in production.
• Version drift: A routine Laravel/Symfony component upgrade breaks the bundle's constraints, blocking framework upgrades.
• Event store coupling: Schema migrations for the event store live outside Laravel's migration tooling, creating two migration systems to operate.
• Projection lag/rebuild: Replays and read-model rebuilds have no first-class Laravel operational story here.

Ramp-up: Steep and compound. The team must absorb CQRS/Event Sourcing concepts, Broadway's API, Symfony DI conventions, and the bridging layer into Laravel — three distinct learning curves for a package with no documentation ecosystem and no users to learn from. Budget for a senior engineer to own this end-to-end, or choose a Laravel-native alternative and avoid the mismatch entirely.