Prooph Event Store Doctrine Adapter Bundle Laravel Package

Technical Evaluation

Architecture Fit

• Event Sourcing Alignment: The package bridges Prooph Event Store (a CQRS/ES library) with Doctrine ORM, enabling persistence of events via Doctrine’s repository pattern. This is ideal for applications already using Symfony + Doctrine but needing event sourcing or CQRS patterns.
• Symfony Ecosystem: Designed for Symfony bundles, leveraging Symfony’s dependency injection (DI) and configuration system. Minimal friction for teams already using Symfony.
• Domain-Driven Design (DDD) Fit: Aligns well with aggregate roots, event streams, and event repositories—key DDD concepts. Useful for complex domains requiring auditability, replayability, or eventual consistency.

Integration Feasibility

• Doctrine ORM Dependency: Requires Doctrine DBAL (minimum) or Doctrine ORM (recommended). If the app already uses Doctrine, integration is straightforward.
• Prooph Event Store Dependency: Introduces Prooph Event Store (a standalone library) as a new dependency. Requires understanding of event stores, event streams, and event publishing.
• Configuration Overhead: Symfony bundle structure means additional config/packages/ files and potential service overrides. May require custom Doctrine entity mappings for events.

Technical Risk

• Learning Curve: Event sourcing introduces new paradigms (e.g., event versioning, snapshotting, projections). Teams unfamiliar with CQRS/ES may face adoption resistance.
• Performance Implications:
  • Event Storage: Storing events as Doctrine entities may not be optimal for high-throughput systems (consider Prooph’s native storage adapters like pdo or mongodb for scalability).
  • Querying: Doctrine’s ORM is not optimized for event replay or projection queries (may need custom repositories or read models).
• Schema Migrations: Events are immutable; schema changes (e.g., adding fields) require backward-compatible event versions or migration strategies (e.g., Prooph’s EventStore versioning).
• Testing Complexity: Event-sourced systems require temporal testing (e.g., replaying events to verify state). May need custom test fixtures or tools like Prooph’s EventPublisher mocks.

Key Questions

1. Why Event Sourcing?
   • Is this for auditability, replayability, or decoupling? Aligns with business needs to justify complexity.
2. Storage Backend:
   • Will Doctrine ORM suffice, or should we use Prooph’s native pdo/mongodb adapter for performance?
3. Event Versioning:
   • How will we handle breaking changes in event schemas? (e.g., adding required fields)
4. Read Models/Projections:
   • How will we query events efficiently? Will we use Doctrine queries, custom projections, or Elasticsearch?
5. Symfony Compatibility:
   • What Symfony version is the target? (Bundle may need updates for Symfony 6+.)
6. Existing Event Infrastructure:
   • Does the app already use message queues (e.g., Symfony Messenger) for async event publishing?
7. Team Expertise:
   • Does the team have experience with CQRS/ES? If not, budget for training or mentorship.

Integration Approach

Stack Fit

• Symfony + Doctrine: Native fit. The bundle is designed for this stack, with minimal boilerplate.
• Prooph Event Store: Adds event-sourcing capabilities. Complements Symfony’s Messenger component (if used for async event publishing).
• Alternatives Considered:
  • Prooph’s native Doctrine adapter (without Symfony bundle): More control but higher setup effort.
  • Other event stores (e.g., Laravel’s spatie/laravel-event-sourcing, Axon Framework): May fit better for non-Symfony apps.

Migration Path

1. Assess Current State:
   • Audit existing entity models, repositories, and business logic to identify aggregate roots and events.
2. Incremental Adoption:
   • Start with one aggregate root (e.g., Order) and its events.
   • Replace CRUD operations with event publishing (e.g., OrderCreated, OrderCancelled).
3. Doctrine Configuration:
   • Define Doctrine entities for events (e.g., OrderCreatedEvent).
   • Configure the bundle in config/packages/david2m_prooph_event_store.yaml.
4. Event Store Setup:
   • Initialize the event store with a stream name (e.g., order-{id}).
   • Replace direct entity persistence with event publishing via Prooph’s EventPublisher.
5. Projection Layer:
   • Build read models (e.g., OrderView) to materialize state from events (using Doctrine queries or custom projections).
6. Testing:
   • Write event replay tests to verify aggregate state.
   • Test event versioning if schemas evolve.

Compatibility

• Doctrine ORM: Works with Doctrine 2.7+. May need adjustments for Doctrine 3.x (if released).
• Symfony: Tested with Symfony 5.x. Check for Symfony 6/7 compatibility (e.g., autowiring, flex recipes).
• PHP Version: Requires PHP 8.0+ (Prooph Event Store dependency).
• Database: Supports any Doctrine-supported DB (MySQL, PostgreSQL, etc.). Performance may vary for high-write workloads.

Sequencing

Operational Impact

Maintenance

• Dependency Management:
  • Prooph Event Store and Doctrine updates may require bundle updates. Monitor for breaking changes.
  • Event Schema Changes: Requires careful versioning (e.g., adding optional fields, using EventStore::withMetadata()).
• Doctrine Migrations:
  • Events are immutable; schema changes must be backward-compatible or handled via event versioning.
  • Use Doctrine Migrations for initial setup but avoid altering event tables post-deployment.
• Logging/Monitoring:
  • Track event publishing failures, stream loading times, and projection lag.
  • Example metrics:
    • Events published/sec.
    • Event store read latency.
    • Projection consistency delays.

Support

• Debugging Complexity:
  • Event replay debugging: Use Prooph’s EventStore::load() to inspect streams.
  • State inconsistency: Verify projections match event streams (e.g., php bin/console debug:event-store).
• Common Issues:
  • Concurrency conflicts: Handle with optimistic locking (e.g., ExpectedVersion in Prooph).
  • Missing events: Ensure all commands publish events (use symfony/var-dumper for debugging).
  • Performance bottlenecks: Optimize Doctrine queries for event loading.
• Documentation Gaps:
  • Bundle lacks usage examples (e.g., Symfony 6 config, async event publishing). May need internal docs.

Scaling

• Write Scaling:
  • Doctrine ORM may become a bottleneck for high-throughput event publishing. Consider:
    • Batch publishing (e.g., Symfony Messenger with batch handlers).
    • Native Prooph adapters (e.g., pdo with bulk inserts).
  • Database connection pooling: Use PdoConnection with connection reuse.
• Read Scaling:
  • Event replay: Loading large streams may be slow. Use pagination or projections.
  • Read models: Offload queries to Elasticsearch or Redis for projections.
• Horizontal Scaling:
  • Statelessness: Ensure aggregate handlers are stateless (e.g