Event Engine Symfony Bundle Laravel Package

Technical Evaluation

Architecture Fit

• Event-Driven Paradigm Alignment: The package bridges Event Engine (a CQRS/ES framework) with Symfony, making it a strong fit for Laravel applications requiring event sourcing, CQRS, or domain-driven design (DDD). Laravel’s ecosystem (e.g., Laravel Events, Queues) can be extended to adopt this pattern with minimal refactoring.
• Symfony-to-Laravel Compatibility:
  • Symfony’s Messenger, Lock, and Cache components are analogous to Laravel’s Queues, Semaphore, and Cache systems, respectively.
  • Prooph Event Store (used here) can be replaced with Laravel’s database-backed event storage (e.g., spatie/laravel-event-sourcing) or custom implementations via illuminate/support traits.
• Domain-Specific Constraints:
  • The bundle assumes PostgreSQL (via event-engine/php-postgres-document-store), which may require Laravel-specific adaptations (e.g., spatie/laravel-postgres or raw PDO).
  • JSON Schema validation (opis/json-schema) can be mapped to Laravel’s API Resources or Form Request validation.

Integration Feasibility

• Core Dependencies:
  • Event Engine PHP (event-engine/php-engine) is the primary abstraction layer. Laravel can integrate this via service providers or facades, though Symfony’s Bundle structure will need translation (e.g., Laravel\Package\ServiceProvider).
  • Prooph Event Store can be swapped for Laravel-native solutions (e.g., spatie/laravel-event-sourcing or custom EventStore class).
• Symfony-Specific Components:
  • Messenger → Laravel Queues (e.g., bus/laravel-queue or spatie/laravel-queue).
  • Lock → Laravel Semaphore or Redis locks (predis/predis).
  • PropertyInfo → Laravel Reflection or Laravel’s Illuminate\Support\Traits\Macroable.
• Validation/Schema:
  • opis/json-schema can be replaced with Laravel’s Validator or API Resources for request/response validation.

Technical Risk

• High Coupling to Symfony:
  • The bundle’s Bundle structure and Symfony-specific services (e.g., ContainerAware) will require abstraction layers to work in Laravel.
  • Risk Mitigation: Use adapters (e.g., Symfony\Component\HttpKernel\KernelInterface → Laravel’s Illuminate\Contracts\Http\Kernel) or decorators to wrap dependencies.
• PostgreSQL Dependency:
  • If the app uses MySQL, the php-postgres-document-store must be replaced with a MySQL-compatible store (e.g., prooph/pdo-event-store with Laravel’s DB facade).
• Event Engine Maturity:
  • The underlying Event Engine (~0.1) is pre-1.0, introducing API instability risk. Validate backward compatibility or fork for stability.
• Testing Overhead:
  • The package lacks Laravel-specific tests. Custom test suites (e.g., pestphp/pest) will be needed for edge cases.

Key Questions

1. Why Event Sourcing?
   • Does the Laravel app need audit logs, time-travel debugging, or projection-based reads? If not, simpler Laravel Events may suffice.
2. Storage Backend:
   • Can PostgreSQL be avoided? If yes, how will php-postgres-document-store be replaced?
3. Symfony vs. Laravel Abstractions:
   • Which Symfony components are critical (e.g., Messenger)? Can they be 1:1 mapped to Laravel?
4. Performance:
   • Event sourcing adds write overhead. Is the app’s throughput compatible with async event processing?
5. Team Expertise:
   • Does the team have experience with CQRS/ES? If not, ramp-up time may delay adoption.
6. Fork vs. Adapt:
   • Given the bundle’s non-generic config, should the team fork or build a Laravel-specific wrapper?

Integration Approach

Stack Fit

Migration Path

1. Phase 1: Proof of Concept (PoC)

   • Isolate one domain (e.g., Orders) and implement Event Sourcing without the bundle.
   • Use:
     • spatie/laravel-event-sourcing for storage.
     • Laravel Queues for async event handling.
     • Custom Event classes extending Laravel’s base Event class.
   • Validate if the business value justifies the complexity.

2. Phase 2: Bundle Integration (Hybrid Approach)

   • Fork the bundle and adapt it for Laravel:
     • Replace Symfony\Component\HttpKernel\Bundle\Bundle with Illuminate\Support\ServiceProvider.
     • Abstract Symfony services (e.g., Messenger → Illuminate\Bus\Dispatcher).
     • Use Laravel’s IoC container (app()->bind()) instead of Symfony’s Container.
   • Example structure:

     // app/Providers/EventEngineServiceProvider.php
     public function register() {
         $this->app->singleton(EventEngine::class, fn() => new EventEngine(
             new ProophEventStore($this->app['db.connection']),
             new LaravelMessageBus($this->app['bus'])
         ));
     }
     

3. Phase 3: Full Adoption

   • Migrate all event-driven logic to use the adapted bundle.
   • Replace remaining Symfony-specific code (e.g., PropertyInfo → Laravel Reflection).
   • Implement projections (read models) using Laravel’s Eloquent or API Resources.

Compatibility

• Laravel 10/11:
  • PHP 8.1+ compatibility aligns with Laravel’s requirements.
  • Symfony 6/7 components are mostly compatible (e.g., Messenger, Cache).
• Existing Laravel Ecosystem:
  • Queues: Works with Laravel’s queue:work and queue:listen.
  • Testing: Replace phpunit with pestphp/pest for Laravel-specific assertions.
  • Validation: Use Laravel’s FormRequest or Validator facade.

Sequencing

1. Prerequisites:
   • Upgrade Laravel to PHP 8.1+ (if not already).
   • Install PostgreSQL (or alternative storage) and prooph/pdo-event-store.
2. Core Integration:
   • Add the forked bundle via Composer (with replace for Symfony dependencies).
   • Register the ServiceProvider in config/app.php.
3. Event-Driven Workflows:
   • Define Aggregate Roots (Laravel models with event sourcing).
   • Implement handlers as Laravel Jobs/Listeners.
4. Read Models:
   • Build projections using Laravel’s Eloquent or API Resources.
5. Testing:
   • Write Pest tests for event publishing/consumption.
   • Test failure scenarios (e.g., queue failures, lock timeouts).

Operational Impact

Maintenance

• Dependency Management:
  • Event Engine (~0.1) is a high-maintenance risk. Pin versions strictly or fork for stability.
  • Symfony components (e.g., Messenger) may require updates when Laravel upgrades PHP/Symfony dependencies.
• Custom Abstractions:
  • The forked bundle will need ongoing Laravel-specific fixes (e.g., container binding changes).
• Documentation:
  • No Laravel docs exist. The team must document:
    • Event publishing/consumption workflows.
    • Error handling (e.g., failed events).
    • Projection update strategies.

Support

• Debugging Complexity:
  • Event Sourcing adds layers of indirection (events → projections). Debugging may require:
    • Event replay tools (e.g., tighten/laravel-event-replayer).
    • Logging all published events (e.g., `