Broadway Bundle Laravel Package

Technical Evaluation

Architecture Fit

• Event Sourcing & CQRS Alignment: The package (ddd-module/broadway-bundle) integrates Broadway, a PHP event-sourcing library, into Symfony, making it a strong fit for architectures requiring auditability, replayability, and eventual consistency. Ideal for domains where domain-driven design (DDD) principles (e.g., aggregates, commands, events) are prioritized.
• Symfony Ecosystem Synergy: Leverages Symfony’s dependency injection, configuration, and HTTP layers, reducing boilerplate for event-driven workflows (e.g., API commands triggering domain events).
• Separation of Concerns: Broadway’s event store and read models decouple write and read operations, enabling optimized queries (e.g., Elasticsearch, Doctrine projections) without polluting the write path.

Integration Feasibility

• Low-Coupling Design: Broadway operates independently of Symfony’s ORM, allowing integration with Doctrine, MongoDB, or custom event stores (e.g., PostgreSQL JSONB, DynamoDB).
• Flexible Persistence: Supports in-memory (dev/testing) and persistent (prod) event stores (e.g., broadway/event-store-doctrine, broadway/event-store-pdo). Requires explicit configuration for production-grade durability.
• Command Bus Integration: Broadway’s command bus can replace or augment Symfony’s Messenger or Console components, though overlap may require careful design (e.g., middleware alignment).

Technical Risk

• Maturity & Adoption: 0 stars/dependents and no active community (last release: 2025-01-10) signal uncertain long-term viability. Risk of abandoned maintenance or breaking changes.
• Learning Curve: Broadway’s event-sourcing paradigm (e.g., event versioning, snapshotting) may require team upskilling if unfamiliar with CQRS/ES.
• Symfony Flex Dependency: Relies on Symfony Flex for autoconfiguration, which could complicate custom bundle setups or non-standard Symfony versions.
• Performance Overhead: Event stores (e.g., Doctrine projections) may introduce latency if not optimized (e.g., batching, indexing). Requires benchmarking for high-throughput systems.

Key Questions

1. Why Broadway over alternatives?
   • Compare to Symfony Messenger + Doctrine Event Store, Prooph, or Cycle ORM’s event sourcing.
   • Does the team need Broadway-specific features (e.g., event versioning, replayable projections)?
2. Persistence Strategy
   • Is the default in-memory store acceptable for dev, or must a persistent store (e.g., PostgreSQL, MongoDB) be implemented immediately?
   • How will read models (e.g., Elasticsearch, Redis) be synchronized with event streams?
3. Error Handling & Retries
   • How will failed commands/events be retried? (Broadway lacks built-in retry logic; may need custom middleware.)
   • What’s the rollback strategy for failed aggregates?
4. Testing & Debugging
   • How will event replay be tested? (Broadway supports replay, but tooling may be lacking.)
   • Are there observability tools (e.g., event store UI, metrics) for production debugging?
5. Team Readiness
   • Does the team have event-sourcing experience? If not, what’s the training/ramp-up plan?
   • Will legacy systems (non-event-sourced) need to integrate? (e.g., via adapters.)

Integration Approach

Stack Fit

• Symfony Core: Seamless integration with Symfony 6.4+ (Flex-compatible). Leverages:
  • Dependency Injection for Broadway services (e.g., CommandBus, EventStore).
  • Configuration via config/packages/broadway.yaml.
  • HTTP Layer: Commands can be triggered via Symfony controllers or Messenger transports.
• Database Layer:
  • Write Path: Event store backends (e.g., broadway/event-store-doctrine for PostgreSQL/MySQL).
  • Read Path: Projections to Doctrine entities, Elasticsearch, or custom read models.
• Messaging:
  • Commands: Can replace or extend Symfony’s Messenger (e.g., for long-running workflows).
  • Events: Published to Symfony’s EventDispatcher or a dedicated event bus (e.g., RabbitMQ).

Migration Path

1. Proof of Concept (PoC)
   • Start with in-memory event store for a single aggregate (e.g., Order).
   • Implement one command (e.g., CreateOrderCommand) and one event (e.g., OrderCreated).
   • Verify event replay and projection updates.
2. Persistent Store Rollout
   • Replace in-memory store with Doctrine PDO or MongoDB for durability.
   • Configure event versioning if aggregates evolve.
3. Read Model Integration
   • Add projections to sync read models (e.g., Elasticsearch for search, Redis for caching).
   • Implement event handlers for side effects (e.g., notifications, analytics).
4. Command Bus Migration
   • Gradually replace Symfony Messenger or console commands with Broadway’s CommandBus.
   • Use middleware to bridge old and new systems (e.g., translate Messenger messages to Broadway commands).
5. Observability & Monitoring
   • Instrument Broadway components (e.g., event store queries, command failures).
   • Add health checks for event store connectivity.

Compatibility

• Symfony Versions: Officially supports Symfony 6.4+ (check broadway-bundle docs for exact versions).
• PHP Versions: Requires PHP 8.1+ (align with Symfony’s LTS support).
• Event Store Backends:
  • Doctrine: Works with Doctrine DBAL (not full ORM).
  • PDO: Supports PostgreSQL, MySQL, SQLite.
  • MongoDB: Requires broadway/event-store-mongodb.
• Conflict with Other Bundles:
  • Symfony Messenger: Can coexist but may need duplication avoidance (e.g., same command handled by both).
  • Doctrine ORM: Broadway’s event store is separate; no direct conflict but may require transaction management (e.g., EventStore outside Doctrine transactions).

Sequencing

Operational Impact

Maintenance

• Bundle Updates: Low risk if using SemVer (MIT license allows forks if upstream stalls).
• Dependency Management:
  • Broadway Core: Updates may require event versioning adjustments.
  • Event Store Backends: E.g., Doctrine DBAL updates may need schema migrations.
• Schema Migrations:
  • Event Store: Schema changes are backward-compatible if versioned.
  • Read Models: Projections may need manual updates if event structures change.

Support

• Community: No active community (0 stars, no GitHub issues). Support relies on:
  • Documentation: broadway.github.io (check for completeness).
  • Freenode IRC: #qandidate (unreliable for urgent issues).
  • Forking: May need to maintain a private fork for critical fixes.
• Debugging:
  • Event Replay: Useful for debugging but requires manual setup (no built-in UI).
  • Logging: Broadway provides basic logging; may need custom logging middleware.
• Vendor Lock-in: Low (Broadway is a standard; switching to another ES library is feasible).

Scaling

• Horizontal Scaling:
  • Event Store: Must support distributed reads/writes (e.g., PostgreSQL with read replicas).
  • Command Processing: Broadway’s CommandBus is stateless; scale workers horizontally.
• Performance Bottlenecks:
  • Event Store Writes: High-throughput systems may need **