Broadway Bundle Laravel Package

Product Decisions This Supports

• Event Sourcing / CQRS architecture bet: Choosing Dublin Bundle is effectively a commitment to event sourcing for at least one bounded context. This decision sits upstream of most product-engineering trade-offs (auditability, temporal queries, replay, eventual consistency), so it should be scoped to a specific high-value domain rather than adopted platform-wide.
• Build vs. buy (vs. fork): The existence of a maintained community fork is a signal in itself — the original Broadway Bundle is unmaintained, so "stay on Broadway" is a silent liability. Options collapse to: (a) adopt Dublin Bundle, (b) fund an internal fork, or (c) drop event sourcing for that context. This release makes (a) viable for the first time with a stable 1.0.
• Framework-alignment decision: This is a Symfony bundle, not a Laravel package. For a Laravel-first org, the realistic decision is whether to (i) accept a Symfony service in the stack, (ii) use Dublin standalone (it's framework-agnostic; the bundle is just DI/config wiring), or (iii) defer until framework-agnostic integration is proven. Roadmap planning should not assume Laravel-native support.
• Upgrade-path / technical-debt roadmap: 1.0.0 is explicitly a drop-in replacement for broadway/broadway-bundle, giving a cheap migration story for any legacy Broadway services. This is a "reduce risk at low cost" item that can slot into an existing maintenance window rather than a dedicated initiative.
• Supportability and platform-cost planning: A single-maintainer fork is a real supply-chain consideration. PM input should include a contingency (vendoring, internal fork budget, or abstraction seams) rather than assuming long-term upstream support.
• Use cases worth prototyping: audit-critical workflows (ledger, billing, compliance trails), long-lived aggregates with complex state transitions, and any domain where "what did the system believe on date X?" is a product requirement — not CRUD-shaped admin features.

When to Consider This Package

Consider it when:

• You already run (or are willing to run) Symfony, and need first-class DI/config wiring for Dublin 3.x.
• You have an existing Broadway Bundle integration and want off an unmaintained dependency with minimal code change — this is the clearest, lowest-risk adoption case.
• Event sourcing is genuinely justified: auditability, replay, temporal queries, or regulatory retention are product requirements, not architectural fashion.
• You can accept a community-maintained, single-primary-maintainer dependency with a documented fallback plan.
• You need a stable, versioned baseline (1.0.0) rather than a pre-1.0 API that shifts under you.

Look elsewhere / defer when:

• Your stack is Laravel. There is no Laravel integration here. Evaluate Dublin as a standalone library, or use a Laravel-native event-sourcing package, before committing. Do not let the "PHP package" framing obscure this.
• The domain is straightforward CRUD or reporting — event sourcing adds operational and cognitive overhead with little product payoff.
• You require vendor SLAs, commercial support, or a multi-maintainer guarantee.
• You need a migration path off Broadway with automated tooling — this is a dependency swap, not a data migration guide; plan persistence/serialization compatibility testing yourself.
• No one on the team has run an event-sourced system in production (projections, replay, schema evolution, snapshots).

Adoption gates: pin to matiux/dublin-bundle ^1.0 with Dublin ^3.x; validate the Broadway→Dublin swap against existing event streams in a staging environment before production; confirm the maintained Symfony/PHP version matrix matches your runtime; verify the maintainer's release cadence over the last 6–12 months.

How to Pitch It (Stakeholders)

For executives — one paragraph: We identified that a dependency underpinning our event-sourced components (Broadway Bundle) is no longer maintained, which is a quiet but real operational risk. A community fork, Dublin Bundle, has just reached a stable 1.0 with a drop-in replacement path and current Symfony support. Recommended action is a low-cost, time-boxed evaluation in one bounded context — no new platform bet, no rewrite. The decision being asked for is approval of that spike, not commitment to the technology.

For engineering — the substance: Dublin Bundle 1.0.0 is the first stable release of a maintained fork of Broadway Bundle, providing Symfony integration for the Dublin CQRS/Event Sourcing library. It targets modern Symfony and Dublin 3.x, and is intended as a drop-in replacement for broadway/broadway-bundle (swap the Composer dependency, update config, follow the README). It is not a Laravel package — treat it as Symfony-only, or use Dublin standalone if we're on Laravel. Risks to state plainly: single-maintainer project, no commercial support, and a "drop-in" claim that still requires us to prove serialization and stream compatibility against real data. Mitigation: vendor or pin the dependency, keep the event-sourcing boundary behind our own interfaces so the library stays swappable, and budget an internal-fork contingency.

What we're explicitly not claiming: that this is production-proven at our scale, that migration is zero-effort, or that event sourcing is the right default for new features. This release removes a maintenance blocker; it does not by itself justify broader architectural change.