Broadway Laravel Package

Technical Evaluation

micro-module/broadway positions itself as a thin infrastructure and testing-helper layer over the Broadway CQRS/event-sourcing primitives, presumably providing Laravel service-container bindings, configuration, and test doubles for aggregates, command buses, and event stores. The value proposition is real: Broadway itself is unopinionated and wiring it into Laravel (bindings for CommandBus, EventBus, EventStore, serializers, and read-model projections) is repetitive glue that every team rewrites. The question is whether this specific package is the right vehicle.

Architecture fit. Conceptually clean — CQRS/ES is a deliberate architectural commitment, not a library you sprinkle in. The package's role is composition-root plumbing, which is exactly where a Laravel package earns its keep. However, event sourcing imposes hard constraints that propagate far beyond the package: append-only event schemas become a public contract, projections become separately deployable concerns, and read/write consistency becomes eventual. If the wider platform is a conventional CRUD Laravel app, adopting this package is adopting a paradigm, not a dependency.

Integration feasibility. Mechanically straightforward — a Composer require plus a service provider — but viability hinges on version alignment across four axes: the Laravel major, the PHP runtime, the underlying broadway/broadway release line, and the chosen event-store backend (Doctrine DBAL, MongoDB, or an in-memory store for tests). A helper package pinned to an older Broadway major will silently constrain the whole application's upgrade path.

Technical risk. The adoption signals are the dominant risk, not the code quality: 0 stars, 0 dependents, no release since July 2023, and a single-maintainer surface. That combination means no downstream pressure to keep it compatible with new Laravel or PHP releases, no community CVE triage, and no regression reports from other users. The "opportunity" score in the low range reinforces that this is not a package the ecosystem is converging on. The testing helpers are the most valuable and also the most fragile piece — they tend to couple to internal Broadway APIs, which are the least stable surface.

Key questions.

• Which broadway/broadway major and which Laravel/PHP versions are actually supported, and is there a CI matrix proving it?
• Does it own the event store implementation, or delegate to Broadway's serializers and stores? The former is a fork we must maintain; the latter is replaceable glue.
• Are the testing helpers assertions against public Broadway interfaces or reflection into internals?
• Is the event serialization format documented and stable enough to survive the package being removed later?
• What is the maintainer's intent — a personal scaffold, or an intended product?

Verdict. Treat as a reference implementation to copy, not a dependency to adopt, unless the answers above reveal it is genuinely thin glue and we are prepared to fork it.

Integration Approach

Stack fit. Suitable only for a Laravel service that has already decided event sourcing is correct for a bounded context with genuine audit/replay requirements — payments ledger, order lifecycle, inventory movements. It is a poor fit for a greenfield CRUD app, for a team with no ES experience, or for any context where the event schema will churn weekly. Isolate adoption to one bounded context; do not make it the default application architecture.

Migration path. Do not attempt an in-place migration of existing CRUD tables into event streams. Instead: stand up a new bounded context alongside the existing app, publish integration events from the legacy side through a thin translation layer, and let the event-sourced context consume them. Keep the legacy read models serving traffic until the new projections have proven parity. The migration is strangler pattern with an event boundary, not a database rewrite.

Compatibility. Pin exact versions in composer.json — Laravel major, PHP minor floor, Broadway major, and the event-store driver. Verify the Broadway major explicitly; a mismatch here is the single most likely cause of a failed spike. Confirm the event store backend before anything else: Doctrine DBAL is the pragmatic default for an existing RDBMS, MongoDB if the team already operates it, and the in-memory store must never reach production. Build a compatibility matrix as a CI job rather than a wiki page.

Sequencing.

1. Two-day spike (timeboxed). Install, wire one aggregate, one command, one event, one projection, and run the test helpers. Output: a go/no-go memo and a version matrix.
2. Fork decision. If the spike passes, vendor the package into our monorepo under a maintained namespace — we take ownership of upgrades at that moment. If it fails, use broadway/broadway directly plus ~200 lines of our own service-provider glue; this is a low-cost fallback and should be the default expectation.
3. Contract freeze. Define event schema conventions (naming, versioning, upcasting strategy) before writing the second aggregate. Retrofitting upcasting is expensive.
4. Projection infrastructure. Decide synchronous vs. queued projections up front; synchronous projections inside the HTTP request are the most common cause of latency regressions.
5. Pilot one context, with a rollback plan that leaves the legacy path fully intact.

Operational Impact

Maintenance. The true cost is fork ownership. With one maintainer and no recent releases, assume we will be the ones bumping Broadway and Laravel compatibility. Budget roughly a few engineer-days per Laravel major upgrade for the glue plus a periodic review of Broadway upstream. This is acceptable for a package of this size; it is not acceptable if the package has grown to own serialization or store internals — that is the deciding factor.

Support. No community, no issue-tracker velocity, no vendor. Internal documentation and an owned README become mandatory. Onboarding cannot rely on "search the docs."

Scaling. Scaling characteristics belong to the event store and projection layer, not to this package: append throughput, stream length, snapshot frequency, and rebuild time for projections. Long-lived aggregates with thousands of events will degrade without snapshots. Projection rebuilds grow linearly with total event count and must be rehearsed — a rebuild that takes hours is an outage during an incident. Read models scale independently and horizontally if projections are queue-driven; they do not if they are inline.

Failure modes to design for.

• Projection lag or stall — consumers fall behind silently; requires lag metrics and alerting.
• Duplicate or out-of-order delivery — handlers must be idempotent; assume at-least-once.
• Event schema drift — a field renamed in an aggregate breaks replay of historical events; upcasting must exist before the second version of any event.
• Partial write — event persisted but projection not updated, producing inconsistent reads; needs a reconciliation job.
• Upstream abandonment — a Laravel major release ships, the package does not, and the application is blocked; mitigated only by the fork.
• Silent misconfiguration — in-memory store or sync bus reaching production, which looks healthy until it loses all state.

Ramp-up. The dominant cost is not the package but event sourcing itself: developers must internalize aggregate boundaries, command/event separation, eventual consistency, and replay-based debugging. Plan for weeks, not days, before a team is productive, and expect the first aggregate design to be wrong. Pair the rollout with a written internal playbook, a reference aggregate, and a review gate on event schema changes. Given the low adoption signal and stale release cadence, the recommendation to leadership is: fund the spike, plan on forking or inlining the glue, and gate the paradigm decision separately from the package decision — the package is replaceable in an afternoon; the architecture is not.