Event Store Laravel Package

Technical Evaluation

Architecture Fit

• Event Sourcing Pattern Alignment (Unchanged, but with updated context)

  • Remains a native fit for ES/CQRS, with append-only semantics and immutable event history.
  • Strengths:
    • Roave BC Checker integration (v7.12.3) enforces backward compatibility, reducing risk of breaking changes in event schemas.
    • PHPUnit compatibility fixes align with modern testing practices (critical for Laravel’s testing stack).
  • Weaknesses:
    • Abstract test class renames (due to PHPUnit changes) may require refactoring in custom test suites (see Key Questions).

• Domain-Driven Design (DDD) Synergy (Unchanged)

  • Still aligns with aggregate roots and domain events, but now with enforced BC checks for event classes.

Integration Feasibility

• PHP Ecosystem Compatibility (Updated)

  • PHP 8.1+ remains recommended, but PHPUnit 10+ is now explicitly supported (critical for Laravel’s built-in testing).
  • Roave BC Checker adds a pre-commit hook opportunity to validate event schema changes before deployment.
  • Doctrine DBAL remains default, but custom adapters (e.g., Redis) may need PHPUnit test updates if using prooph’s test utilities.

• Laravel-Specific Considerations (Unchanged, but with caveat)

  • No native Laravel integration, but PHPUnit compatibility means Laravel’s testing tools (e.g., Pest, PHPUnit) will work seamlessly.
  • Caveat: Custom test classes extending prooph’s renamed abstract classes will break and require refactoring.

Technical Risk

Key Questions (Updated)

1. Storage Backend (Unchanged)
   • Will we use Doctrine DBAL (SQL) or a custom adapter (e.g., Redis)? What are the trade-offs?
2. Event Schema (Updated)
   • How will we integrate Roave BC Checker into our CI/CD pipeline to enforce backward compatibility?
   • Will we refactor custom test classes extending prooph’s renamed abstract classes (e.g., AbstractEventStoreTest)?
3. Read Models (Unchanged)
   • Will we use prooph/event-store’s projections or separate read models?
4. Concurrency Control (Unchanged)
   • How will we handle conflicts in event appends?
5. Observability (Unchanged)
   • What metrics/logging will we implement for event store health?
6. Migration Path (Updated)
   • If migrating from a legacy system, how will we backfill events while ensuring BC compliance with Roave checks?
7. Testing Strategy (New)
   • How will we update Laravel test suites to avoid breaking changes from PHPUnit compatibility fixes?

Integration Approach

Stack Fit (Updated)

• Core Stack Compatibility:

  • PHP 8.1+ (recommended) with PHPUnit 10+ (now explicitly supported).
  • Laravel 9/10 remains fully compatible; Pest/PHPUnit testing tools will work without issues.
  • Roave BC Checker can be added to Laravel’s CI pipeline (e.g., GitHub Actions) to validate event schemas.
  • Doctrine DBAL or custom storage (e.g., Redis) remains viable, but test utilities may need updates.

• Optional Integrations (Unchanged)

  • prooph/service-bus, Laravel Horizon, and Laravel Echo remain compatible.

Migration Path (Updated)

Compatibility (Updated)

• Laravel-Specific Workarounds (Unchanged, but with testing note)

  • Service provider binding, queue integration, and Artisan commands remain the same.
  • Testing Note: If using prooph’s abstract test classes (e.g., AbstractEventStoreTest), rename or extend new classes (e.g., prooph/event-store-test-case).

• Avoid (Updated)

  • Mixing Eloquent and prooph events (still risky).
  • Assuming ACID transactions (still invalid; use sagas).
  • Ignoring Roave BC Checker warnings in CI (now a blocker for event schema changes).

Sequencing (Unchanged)

1. Start with non-critical aggregates.
2. Implement projections early.
3. Add observability before full rollout.
4. Phase out legacy systems.

Operational Impact

Maintenance (Updated)

• Pros:
  • Roave BC Checker reduces runtime deserialization errors by catching schema issues early.
  • Immutable event store and explicit schema evolution remain low-maintenance.
• Cons:
  • Test suite refactoring required for renamed abstract classes (one-time cost).
  • BC checks add CI overhead but improve long-term stability.
• Tooling (Updated)
  • Integrate Roave BC Checker into Laravel’s php-cs-fixer or GitHub Actions:

    # Example GitHub Actions step
    - name: Check backward compatibility
      run: vendor/bin/roave-bc-check analyze --dir=src --config=bc-config.php
    

  • Use prooph’s EventStoreDebugger and Laravel’s logging for observability.

Support (Updated)

• Debugging:
  • Event replay remains powerful; Roave BC Checker helps isolate schema-related issues.
  • Correlation IDs still aid tracing.
• Common Issues (Updated)
  • Deserialization errors: Now caught earlier by BC checks, but still require manual review for edge cases.
  • Test failures: Expected during migration due to renamed abstract classes.
  • Projection failures: Unchanged; idempotent logic still required.
• Documentation:
  • Prooph’s docs are updated for PHPUnit 10+; supplement with Laravel-specific BC check examples.

Scaling (Unchanged)

• Write Scaling: Batch appends, connection pooling.
• Read Scaling: Projections, read replicas.
• No changes to scaling strategies, but BC checks may reveal bottlenecks in event schema design.

Failure Modes (Updated)