Broadway Laravel Package

Product Decisions This Supports

• Adoption of CQRS/ES Architecture: Enables teams to implement Command Query Responsibility Segregation (CQRS) and Event Sourcing (ES) patterns in PHP/Laravel, reducing tight coupling between read and write models. Ideal for high-scale, audit-heavy, or complex domain-driven applications (e.g., financial systems, e-commerce, or real-time analytics).
• Decoupling Business Logic: Facilitates modular, testable, and maintainable domain logic by separating commands, events, and projections. Supports microservices or monolithic decomposition where bounded contexts are critical.
• Roadmap for Event-Driven Features:
  • Audit Trails: Built-in auditing for command success/failure (via CommandLogger).
  • Real-Time Projections: Read models (e.g., Elasticsearch/MongoDB) enable materialized views for fast queries.
  • Saga Orchestration: Extensible via broadway-saga for long-running transactions (e.g., order fulfillment workflows).
• Build vs. Buy:
  • Buy: Use Broadway to avoid reinventing CQRS/ES infrastructure (e.g., event stores, serializers, command buses).
  • Build: Customize components (e.g., swap DBALEventStore for a custom solution) if Broadway’s abstractions are too opinionated.
• Use Cases:
  • Legacy System Modernization: Gradually introduce ES/CQRS to monolithic apps.
  • High-Concurrency Systems: Decouple reads/writes to scale independently.
  • Regulatory Compliance: Immutable event logs for GDPR, SOX, or financial audits.

When to Consider This Package

Adopt Broadway If:

• Your team is familiar with CQRS/ES and needs a PHP-native implementation (not Java/.NET frameworks like Axon or EventStoreDB).
• You’re using Laravel/Symfony and want loosely coupled components (e.g., swap out DBALEventStore for MongoDB later).
• Testing is a priority: Broadway provides scenario-based testing helpers for event-sourced aggregates and command handlers.
• You need auditability (e.g., track who executed a command and why it failed).
• Your domain requires event-driven workflows (e.g., sagas for multi-step processes).

Look Elsewhere If:

• You need real-time event streaming: Broadway lacks native support for Kafka/RabbitMQ (though you could integrate a custom event bus).
• Your team lacks DDD/CQRS expertise: The learning curve for ES patterns is steep; consider simpler ORMs (e.g., Eloquent) or event libraries like [Laravel Events].
• You require high-performance event storage: Broadway’s DBALEventStore may not match the throughput of specialized solutions like EventStoreDB or Apache Kafka.
• You’re not using PHP/Laravel: Broadway is PHP-centric; alternatives like Axon Framework (Java) or Lagom (Scala) may fit better.
• You need graphQL/subscriptions: Broadway focuses on commands/events, not real-time APIs (though you could pair it with Laravel Echo).

How to Pitch It (Stakeholders)

For Executives (Business/Tech Leads):

*"Broadway lets us build scalable, audit-proof systems without reinventing CQRS/Event Sourcing from scratch. Think of it as Lego blocks for:

• Real-time data pipelines (e.g., sync inventory across warehouses via events).
• Unchangeable audit logs (critical for compliance in finance/healthcare).
• Decoupled microservices (write once, query many ways—e.g., APIs, dashboards, or analytics).

Why now?

• Reduces tech debt by avoiding custom event stores/command buses.
• Enables faster feature delivery for complex workflows (e.g., order processing).
• Future-proofs the architecture for growth (e.g., add Elasticsearch projections later).

Risk: Steeper learning curve for the team, but we can start with a pilot project (e.g., a single bounded context like ‘Payments’)."*

For Engineers (Dev/Architecture Teams):

*"Broadway gives us batteries-included CQRS/ES for PHP/Laravel with:

• Modular components: Use just the event store, or the full stack (commands → events → projections).
• Testing superpowers: Built-in helpers for scenario testing (e.g., ‘Given X command, then Y events are emitted’).
• Flexible storage: Swap DBALEventStore for MongoDB/Elasticsearch later.
• Audit trails: Log command failures automatically (no extra boilerplate).

How we’d use it:

1. Start small: Replace a single Eloquent model with an event-sourced aggregate (e.g., UserProfile).
2. Add projections: Sync data to a read model (e.g., Elasticsearch for search).
3. Scale: Extend with sagas or custom event handlers.

Alternatives considered:

• Roll our own: Too much reinvention (e.g., handling snapshots, playhead management).
• EventStoreDB: Overkill for PHP; Broadway is lighter and Laravel-friendly.

Next steps:

• Spike a proof-of-concept (e.g., port a simple feature like ‘User Signup’).
• Compare performance vs. Eloquent for our workload.
• Train the team on DDD/CQRS basics (resources: Broadway docs, EventSourcing.io)."*

For PMs (Product/Feature Owners):

*"Broadway helps us deliver complex features faster by:

• Decoupling reads/writes: Add a new dashboard (read model) without touching the core logic.
• Enabling real-time updates: Push events to services like Twilio (SMS) or Stripe (webhooks) automatically.
• Simplifying rollbacks: Since all state changes are events, we can rewind a user’s account to a previous state if needed.

Example: For a ‘Subscription Management’ feature, we’d:

1. Define commands like UpgradePlanCommand.
2. Let the system emit events like PlanUpgradedEvent.
3. Project these events to a read-optimized table for the UI.
4. Use sagas to handle cross-service workflows (e.g., cancel old plan → create new one).

Trade-offs:

• Upfront cost: 2–4 weeks to onboard the team and build the first aggregate.
• Long-term gain: Easier to add features (e.g., ‘undo’ buttons, analytics) later.

Ask the team:

• Which bounded context (e.g., ‘Payments’, ‘Inventory’) would benefit most from this?
• Can we A/B test Broadway vs. traditional Eloquent for a specific feature?"*