Broadway Bundle Laravel Package

Technical Evaluation

Architecture Fit

• Event Sourcing & CQRS Alignment: The package leverages Broadway, a mature event-sourcing library, which aligns well with Laravel-based architectures requiring auditability, replayability, or complex domain modeling (e.g., financial systems, workflows). The Symfony bundle abstracts Broadway’s core concepts (event stores, read models, sagas) into a Laravel-compatible layer, making it a strong fit for domain-driven design (DDD) or event-driven microservices.
• Symfony vs. Laravel Compatibility:
  • While the package is Symfony-focused, Laravel’s service container can emulate Symfony’s dependency injection (DI) via packages like spatie/laravel-symfony-messenger or custom bridges.
  • Key challenge: Laravel lacks Symfony’s Flex autoconfiguration, requiring manual service registration (e.g., EventStore, CommandBus).
  • Workaround: Use Laravel’s package development tools (e.g., laravel-package-boilerplate) to create a wrapper bundle.

Integration Feasibility

• Core Components:
  • Event Store: Supports DBAL (Doctrine), MongoDB, or custom implementations. Laravel’s Eloquent or Doctrine DBAL (via illuminate/database) can integrate with broadway/event-store-dbal.
  • Read Models: Elasticsearch/MongoDB options exist, but Laravel’s query builder or Scout (for search) may require custom projectors.
  • Command Bus: Broadway’s CommandBus can replace Laravel’s native command bus, enabling asynchronous processing (e.g., via queues).
• Laravel-Specific Gaps:
  • No native Laravel service providers: Requires wrapping Symfony services in Laravel’s ServiceProvider or using Laravel’s Facades.
  • Event Dispatching: Laravel’s Event system differs from Broadway’s DomainEvent. A bridge layer (e.g., converting Laravel events to Broadway domain events) may be needed.
  • Middleware: Broadway lacks Laravel’s middleware pipeline; custom interceptors (e.g., for auth) must be implemented via MetadataEnricher or saga logic.

Technical Risk

Key Questions for Stakeholders

1. Architectural Goals:
   • Is event sourcing a core requirement (e.g., audit trails, time-travel debugging), or is this for scalability (e.g., sagas for long-running workflows)?
   • Will the system need real-time projections (e.g., Elasticsearch) or batch processing (e.g., cron-based read models)?
2. Team Expertise:
   • Does the team have experience with event sourcing or CQRS? If not, budget for training or proof-of-concept (PoC).
   • Is the team comfortable with Symfony’s DI or will a Laravel-native abstraction be needed?
3. Operational Constraints:
   • Are MongoDB/Elasticsearch allowed, or must the solution use SQL-only (e.g., event-store-dbal)?
   • What are the scaling requirements for event storage (e.g., millions of events/day)?
4. Integration Points:
   • How will Broadway commands interact with Laravel’s controllers, jobs, or API routes?
   • Are there existing Laravel events that need to be mapped to Broadway’s DomainEvents?

Integration Approach

Stack Fit

• Laravel Compatibility Matrix:

  Laravel Component	Broadway Equivalent	Integration Strategy
  Eloquent Models	Aggregate Roots	Use Broadway’s AggregateFactory + custom repositories.
  Laravel Queues	Command Bus + Event Store	Dispatch commands via broadway.command_bus; process asynchronously.
  Laravel Events	Domain Events	Create a bridge to emit Laravel events from Broadway projectors.
  Scout/Algolia	Elasticsearch Read Model	Use broadway/read-model-elasticsearch.

  • Recommended Stack:
    • Event Storage: broadway/event-store-dbal (Doctrine DBAL) + Laravel’s database package.
    • Read Models: broadway/read-model-mongodb (if JSON queries needed) or custom Eloquent projectors.
    • Async Processing: Laravel Queues + Broadway’s CommandBus (e.g., dispatchSync() for sync, dispatch() for async).

Migration Path

1. Phase 1: Proof of Concept (PoC)

   • Install broadway/broadway-bundle in a Symfony micro-app (or Laravel with Symfony DI emulation).
   • Implement a single aggregate root (e.g., Order) with:
     • Event store (dbal).
     • In-memory read model (for testing).
     • Basic command handler (e.g., CreateOrderCommand).
   • Validate:
     • Event replay works.
     • Commands can be dispatched from Laravel controllers.
   • Tools: Use laravel-debugbar to inspect Broadway services.

2. Phase 2: Laravel Wrapper Package

   • Create a custom Laravel package (e.g., laravel-broadway) that:
     • Registers Broadway services in Laravel’s container.
     • Provides Facades for CommandBus, EventStore, etc.
     • Bridges Laravel events ↔ Broadway domain events.
   • Example structure:

     /laravel-broadway
       /src
         - BroadwayServiceProvider.php
         - Facades/
           - Broadway.php (e.g., `Broadway::dispatch($command)`)
         - Bridges/
           - LaravelEventToBroadwayBridge.php
     

3. Phase 3: Full Integration

   • Replace Laravel’s native command bus with Broadway’s.
   • Migrate critical aggregates to event-sourced models.
   • Implement read models (e.g., Elasticsearch for search, Eloquent for SQL queries).
   • Add sagas for complex workflows (e.g., order fulfillment).

Compatibility

• Symfony vs. Laravel Differences:
  • Service Registration: Laravel uses bind()/singleton(); Symfony uses set() in config. Use a container adapter (e.g., symfony/dependency-injection in Laravel).
  • Configuration: Symfony’s config/packages/broadway.yaml → Laravel’s config/broadway.php.
  • Routing: Broadway has no routing; use Laravel’s routes to trigger commands (e.g., Route::post('/orders', [OrderController::class, 'create'])->name('orders.create');).
• Dependency Conflicts:
  • Avoid mixing Symfony’s HttpFoundation with Laravel’s Illuminate\Http. Use abstraction layers (e.g., PSR-7 interfaces).

Sequencing

1. Start with a Single Aggregate:
   • Example: User or Order with 2–3 events (e.g., UserRegistered, OrderCreated).
2. Add Persistence:
   • Replace in-memory store with dbal or MongoDB.
3. Implement Read Models:
   • Start with in-memory; migrate to Elasticsearch/MongoDB for production.
4. Introduce Sagas:
   • Only after core aggregates are stable (e.g., for cross-aggregate workflows).
5. Optimize:
   • Add metadata enrichers (e.g., user IDs, timestamps).
   • Implement custom serializers if needed (e.g., for complex payloads).

Operational Impact

Maintenance

• Pros:
  • Decoupled Components: Event store, read models, and sagas can be scaled independently.
  • Auditability: All state changes are stored as events; easy to debug.
  • Backward Compatibility: Broadway’s event store allows replaying from any point in time.
• Cons:
  • Complexity: Event sourcing adds event versioning, serialization, and projection management.
  • **Debugging