Broadway Bundle Laravel Package

Technical Evaluation

Architecture fit Dublin Bundle is a Symfony bundle, not a Laravel package. It integrates via Symfony's kernel/bundle mechanism (Bundle class, DI Extension, Configuration tree, compiler passes). Laravel has no bundle registry; it composes through service providers, facades, and its own container. That mismatch is the dominant finding: the "drop-in replacement" promise applies only to Symfony applications migrating off broadway/broadway-bundle, and does not extend to Laravel. In a Laravel codebase the package can only be consumed as a plain library whose Symfony-style wiring must be hand-rebuilt (service definitions translated to a service provider, config tree replaced with config/*.php, tagged services replaced with explicit bindings).

Integration feasibility Feasible but manual. Expect to: register the underlying Dublin library services yourself, publish/own the event store schema, and re-implement any bundle-provided conveniences (console commands, tagged handler discovery, config normalization). The 1.0.0 delta over 0.7.0 is effectively a rename plus compatibility housekeeping — there is no new capability to justify a fresh integration effort. Any team currently on Broadway Bundle should treat this as a low-effort swap; any team on Laravel should treat it as a from-scratch integration of a CQRS/ES library.

Technical risk

• Single-maintainer fork. Continuity depends on one person maintaining a fork of an upstream (Broadway) that is no longer actively maintained. This is a bus-factor risk, not a code-quality risk.
• Two-hop dependency chain. Dublin → (forked) Broadway lineage → Symfony components. Support windows are set by the fork, not by Symfony.
• Version 1.0.0 is a label, not a stability guarantee. The release notes describe maintenance cleanups; there is no stated BC policy, LTS commitment, or deprecation process.
• Persistence assumptions. Broadway-lineage event stores are Doctrine DBAL-oriented. In Laravel this means either running Doctrine alongside Eloquent or writing a custom event store — a significant, ongoing ownership cost.
• Unknown compatibility matrix. PHP and Symfony version floors are not stated in the notes and must be verified from composer.json before any commitment.
• Licensing/attribution. Inherited Broadway copyright is acknowledged; confirm MIT-compatible terms and preserve notices.

Key questions

1. What are the exact php and symfony/* constraints, and which Symfony versions are in the CI matrix?
2. Is there a documented BC/deprecation policy, or is 1.x expected to track Symfony majors with breaking changes?
3. What actually differs between 0.7.0 and 1.0.0 — renamed namespaces, config root key, service IDs, or only metadata?
4. Is a Laravel adapter, service provider, or Eloquent-compatible event store on the roadmap (or explicitly out of scope)?
5. Does Dublin 3.x require Doctrine DBAL for the event store, and is an alternative (PDO/query-builder) supported?
6. Who else consumes this fork, and what is the release cadence and issue-response history?
7. What is the serializer strategy (Symfony Serializer vs. custom) and how are event schema migrations handled?
8. Is there a migration note for the config/bundles.php class rename and any config key change from broadway to dublin?

Integration Approach

Stack fit Poor for Laravel-first shops; good for Symfony shops already running Broadway. If the goal is CQRS/Event Sourcing inside Laravel, treat this evaluation as "adopt the Dublin library, not the bundle" and budget for an integration layer you own.

Migration path (Symfony, from Broadway Bundle)

1. Swap broadway/broadway-bundle → matiux/dublin-bundle (and Broadway → Dublin 3.x) in composer.json.
2. Update config/bundles.php with the new bundle class.
3. Rename the configuration root key and re-validate against the bundle's Configuration tree.
4. Grep for Broadway namespaces in tagged services, command/event bus wiring, and custom SimpleBus/serializer configuration; alias or update.
5. Run the existing event store schema migration and confirm read/write against a restored production snapshot.
6. Replay a projection in staging before cutover.

Migration path (Laravel)

1. Install Dublin 3.x plus required Symfony components (already transitively present in Laravel).
2. Skip the bundle entirely; write an EventSourcingServiceProvider that binds the command bus, event bus, event store, and repository factory.
3. Decide persistence: Doctrine DBAL connection parallel to Eloquent, or a custom EventStore implementation. Document this as owned code.
4. Port any bundle-provided artisan-equivalents (projection rebuild, event replay) as console commands.

Compatibility Verify PHP floor against the oldest runtime you support and against your Laravel/Symfony version pairing. Because Laravel ships Symfony components at pinned majors, the bundle's Symfony constraints may conflict or over-constrain your framework upgrade path — resolve this in a throwaway branch before committing.

Sequencing Phase 0: dependency spike and constraint resolution (no production code). Phase 1: single bounded context proof of concept with one aggregate, real event store, one projection. Phase 2: operational tooling — replay, rebuild, monitoring. Phase 3: broaden adoption context by context. Do not parallelize Phase 1 and Phase 3; the ES literacy gap is the schedule risk, not the package.

Operational Impact

Maintenance You are adopting a fork of an unmaintained upstream. Assume you may need to vendor or fork again. Budget a standing allocation for dependency bumps on every Symfony/PHP major, and keep the integration layer (especially any Laravel adapter) thin and isolated so a future replacement is a contained change.

Support Community-only: GitHub issues, no SLA, no commercial backing apparent from the release notes. Internal escalation path is "we fix it." Identify an internal owner before adoption; do not let this land as an unowned transitive dependency.

Scaling Event sourcing shifts the scaling problem from request throughput to event store growth and projection throughput. Watch: table/index growth on the event store, snapshot frequency, projection lag, replay duration as the log lengthens, and serializer payload size. Replay time is the metric that quietly becomes an outage during incident recovery — measure it early and keep it inside your recovery objective.

Failure modes

• Projection drift / lag — reads go stale silently; needs lag alerting, not just error alerting.
• Event schema evolution — upcasting gaps produce unreadable history. Require an upcaster policy before the first production event.
• Non-idempotent handlers — at-least-once delivery causes duplicate side effects.
• Serialization drift — class renames or serializer config changes break old events. Pin and version payloads.
• DI compile failures on framework upgrades — bundle config tree rejects new/removed keys at container compile time, i.e., deploy-time breakage, not runtime.
• Abandonment — no upstream security patch for the transitive chain; you inherit the CVE response burden.

Ramp-up The package is the easy part; CQRS/ES is not. Expect a real learning curve for engineers fluent in Laravel's Active Record idioms: aggregates, eventual consistency, projections, replay, and "the event log is the source of truth." In a Laravel shop, add Symfony DI familiarity on top. Plan for one experienced practitioner to own the pattern, a written internal standard for aggregates/events/upcasters, and a code-review checklist. Ramp-up time, not integration time, should drive the delivery estimate.

Recommendation No objection to Dublin Bundle 1.0.0 as a Symfony drop-in replacement for Broadway Bundle — it is a rename-grade release with modern-framework compatibility, and the migration is contained. For a Laravel target, do not adopt the bundle; evaluate the Dublin 3.x library directly, confirm the persistence story, and only proceed if the team has (or will fund) genuine ES capability. Either way, gate on the compatibility matrix and a named internal owner.