Stupid Event Sourcing Symfony Laravel Package

Technical Evaluation

Architecture Fit

• Event Sourcing Alignment: The package provides a Symfony-compatible wrapper for stupid-event-sourcing, a lightweight event-sourcing library built on DBAL (Doctrine DBAL). This fits well in architectures requiring event-driven persistence, audit trails, or CQRS patterns, particularly where Symfony is the primary framework.
• Domain Suitability: Ideal for domains where immutability, temporal queries, or event replay are critical (e.g., financial systems, collaborative editing, or compliance-heavy applications). Less suitable for high-throughput, low-latency systems where event-sourcing overhead may introduce bottlenecks.
• Symfony Ecosystem Synergy: Leverages Symfony’s dependency injection, console commands, and messenger components, reducing boilerplate for event publishing and projection management.

Integration Feasibility

• DBAL Dependency: Requires Doctrine DBAL (v3+) for event storage. If the project already uses Doctrine ORM/DBAL, integration is straightforward. Otherwise, introduces a new dependency.
• Symfony-Specific: Tightly coupled with Symfony’s Console, Messenger, and DI systems. Non-Symfony PHP projects (e.g., Laravel) would need significant abstraction or a custom adapter layer.
• Event Schema: Assumes events are stored as serialized JSON in a dedicated table (event_store). Schema migrations must align with the package’s expectations (e.g., id, aggregate_id, event_name, payload, occurred_at).
• Projection Handling: Uses console commands for projections (e.g., php bin/console es:project). Requires CLI access and may need customization for async projection updates.

Technical Risk

• Laravel Incompatibility: The package is Symfony-only. Key risks:
  • DI Container: Laravel’s container differs from Symfony’s; manual binding or a facade layer would be required.
  • Console Commands: Laravel’s Artisan lacks Symfony’s Command base class. Would need rewriting or a proxy system.
  • Messenger Integration: Laravel’s queue system (e.g., laravel-horizon) isn’t directly compatible with Symfony Messenger. Event dispatching would need custom routing.
• Performance Overhead:
  • Event Storage: DBAL-based storage may not scale as efficiently as specialized event stores (e.g., EventStoreDB, Kafka).
  • Projection Updates: Synchronous console-based projections could block during peak loads.
• Testing Complexity: Event-sourcing introduces temporal testing challenges (e.g., replaying events for state validation). Mocking DBAL or using a test event store would be necessary.
• Vendor Lock-in: Limited adoption (0 dependents) suggests niche use. Custom extensions may be needed for Laravel-specific workflows.

Key Questions

1. Why Event Sourcing?

   • What business requirements justify event sourcing (e.g., auditability, replayability) over traditional CRUD?
   • Are there existing event-driven components in the Laravel stack (e.g., Laravel Echo, queues) that could conflict or duplicate functionality?

2. Stack Compatibility

   • Does the project use Doctrine DBAL? If not, what’s the migration path for event storage?
   • How will Symfony Console commands be invoked in a Laravel context? (e.g., via Artisan aliases or custom CLI tools?)

3. Event Modeling

   • Are events coarse-grained (e.g., OrderCreated) or fine-grained (e.g., OrderItemAdded)? The package assumes events are serialized; complex objects may need custom serialization logic.
   • How will projections (read models) be updated? Will they run in batches, or will async workers (e.g., Laravel Queues) handle them?

4. Performance & Scaling

   • What’s the expected event throughput? DBAL may not handle high write volumes without optimization (e.g., batch inserts, connection pooling).
   • Are there plans for distributed event sourcing (e.g., sharding)? The package doesn’t natively support this.

5. Alternatives

   • Has Laravel-specific event sourcing been evaluated? Options like:
     • spatie/laravel-event-sourcing (simpler, Laravel-native)
     • prooph/event-store (more feature-rich, but heavier)
   • Would a hybrid approach (e.g., using the package’s core logic via a custom Laravel wrapper) be viable?

Integration Approach

Stack Fit

• Laravel Adaptation Layer: The package must be wrapped to fit Laravel’s ecosystem. Key components to abstract:
  • Dependency Injection: Replace Symfony’s ContainerInterface with Laravel’s Illuminate\Container\Container.
  • Console Commands: Create Laravel Artisan commands that delegate to the package’s logic (e.g., php artisan es:project → StupidEventSourcing::project()).
  • Messenger Integration: Build a bridge between Laravel’s queue system and the package’s event dispatcher (e.g., publish events to a queue, then consume them via a worker).
• DBAL Integration:
  • Use Laravel’s DBAL facade (\DB) or Doctrine DBAL (if installed via doctrine/dbal).
  • Ensure the event store table schema matches the package’s expectations (or extend it for Laravel conventions).

Migration Path

1. Proof of Concept (PoC):
   • Isolate event-sourcing logic in a Laravel service provider (e.g., EventSourcingServiceProvider).
   • Test core functionality: storing/replaying events, projecting to a read model.
2. Incremental Rollout:
   • Start with a single aggregate root (e.g., Order) to validate the approach.
   • Gradually migrate other domains as confidence grows.
3. Hybrid Phase:
   • Use the package for write-side logic while keeping read models in Laravel’s Eloquent.
   • Example: Store events via damgru/stupid-event-sourcing-symfony, project to a Laravel table via a scheduled job.

Compatibility

Sequencing

1. Setup:
   • Install damgru/stupid-event-sourcing-symfony and doctrine/dbal (if not present).
   • Configure DBAL connection in config/database.php.
2. Event Store Migration:
   • Create a Laravel migration for the event store table (matching the package’s schema).
   • Example:

     Schema::create('event_store', function (Blueprint $table) {
         $table->id();
         $table->string('aggregate_id');
         $table->string('event_name');
         $table->json('payload');
         $table->timestamp('occurred_at');
     });
     

3. Service Integration:
   • Register the package’s services in a Laravel provider.
   • Example:

     $this->app->bind('event_store', function ($app) {
         return new \Damgru\StupidEventSourcingSymfony\EventStore(
             $app['db']->connection()->getDoctrineSchemaManager()
         );
     });
     

4. Command Layer:
   • Create Artisan commands for projections (e.g., php artisan es:project:run).
5. Domain Integration:
   • Refactor a domain to emit events (e.g., OrderCreated, OrderPaid).
   • Example:

     use Damgru\StupidEventSourcingSymfony\EventStore;
     
     class OrderService {
         public function __construct(private EventStore $eventStore) {}
     
         public function createOrder() {
             $event = new OrderCreated(...);
             $this->eventStore->record('order-123', $event);
         }
     }
     

6. Projection Setup:
   • Define read models (e.g., orders table) and update them via projections.
   • Schedule projections as Laravel commands or queue jobs.

Operational Impact

Maintenance

• Dependency Management:
  • Symfony-Specific Packages: May require forks or patches for Laravel compatibility (e.g., symfony/console → symfony/console polyfill).
  • DBAL Updates: Doctrine DBAL updates may break schema