Prooph V7 Event Store Laravel Package

Technical Evaluation

Architecture Fit

• Event Sourcing & CQRS Alignment: The package remains Prooph Event Store v7, maintaining its alignment with event-driven architectures and CQRS. No changes to core architectural fit; the package still provides a native PHP implementation for event persistence, reducing reliance on external services.
• Domain-Driven Design (DDD) Compatibility: Unchanged—Prooph’s alignment with aggregates, events, and event streams persists. The package continues to streamline event persistence, replay, and projection logic for DDD-adherent applications.
• Laravel Ecosystem Synergy: No modifications to Laravel integration patterns. The package remains non-Laravel-specific, requiring manual wiring with Laravel’s service container and event system.

Integration Feasibility

• Database Backend Flexibility: Unchanged—PostgreSQL, MySQL, and SQLite support via Doctrine DBAL remains intact. No schema or backend compatibility changes.
• Schema Requirements: No updates to required tables (event_store, stream, snapshot). Existing migration adjustments remain necessary if the DB schema is non-standard.
• Laravel Service Provider Integration: Unchanged—bootstrapping via a Laravel Service Provider is still the recommended approach.
• Event Versioning & Metadata: No changes to Prooph’s support for event metadata, versioning, and snapshotting. Existing event models must still implement Prooph\EventStore\Message.

Technical Risk

• Learning Curve for Prooph: Unchanged—team familiarity with Prooph’s concepts (streams, snapshotting, projections) remains a potential hurdle.
• Performance Overhead: No updates to write amplification risks. High-throughput write operations may still require benchmarking.
• Laravel-Specific Gaps:
  • No Eloquent integration: Events must remain plain PHP objects or Doctrine entities.
  • No native Laravel queue integration: Async event processing still requires custom logic.
  • No built-in event publishing/subscription: Laravel’s event system or Prooph’s mechanisms must be manually bridged.
• Migration Complexity: Unchanged—migrating from other event stores (e.g., Redis, custom tables) remains non-trivial.

Key Questions

1. Does the application use event sourcing or CQRS? (Unchanged)
2. What is the current event persistence layer? (Unchanged)
3. Are events currently stored as Eloquent models? (Unchanged)
4. What are the write/read throughput requirements? (Unchanged)
5. Is async event processing needed? (Unchanged)
6. Does the team have experience with Prooph or event-sourced architectures? (Unchanged)
7. Are there existing projections or read models? (Unchanged)
8. What’s the backup/recovery strategy? (Unchanged)

New/Updated Questions Due to Release: 9. Is the application using PHP 8.4? If so, does it rely on deprecated features that this release removes? Could this introduce compatibility issues with existing event classes or Prooph configurations? 10. Are there any third-party libraries or custom code that might depend on PHP 8.4 deprecations now removed? Would this require refactoring?

Integration Approach

Stack Fit

• PHP/Laravel Compatibility:
  • PHP 8.4 Deprecation Fix: The release removes PHP 8.4 deprecations, meaning:
    • If the Laravel app is not on PHP 8.4, this change is non-breaking.
    • If the app is on PHP 8.4, ensure no custom code or dependencies rely on removed deprecation behaviors (e.g., array() constructor, gmp_random()).
  • Composer integration remains unchanged.
• Database Compatibility: Unchanged—PostgreSQL, MySQL, SQLite support persists.
• Event System Synergy: No changes to Laravel event dispatcher or Prooph event store interplay.

Migration Path

1. Assess PHP Version Compatibility:
   • If using PHP 8.4, audit code for removed deprecations (e.g., array() constructor, gmp_random()).
   • Update custom event classes or third-party libraries if they rely on deprecated features.
2. Schema Migration: Unchanged—Prooph’s migrations remain the same.
3. Event Model Adaptation: Unchanged—events must still implement Prooph\EventStore\Message.
4. Service Provider Integration: Unchanged—register EventStore in Laravel’s container.
5. Event Replay & Projections: Unchanged—projections and read models require manual syncing.

Compatibility

• Pros: Unchanged—MIT license, open-source, standardized event storage.
• Cons: Unchanged—no native Laravel ORM support, no built-in pub/sub, no event versioning UI.

New Consideration Due to Release:

• PHP 8.4 Users: If the app uses PHP 8.4, confirm that:
  • Prooph’s removed deprecations do not break event serialization/deserialization.
  • No custom event metadata or aggregate logic relies on deprecated PHP features.

Sequencing

1. Phase 1: Proof of Concept
   • Test Prooph in a non-production environment with the new PHP 8.4-compatible version.
   • If using PHP 8.4, audit for deprecated feature usage in event-related code.
2. Phase 2: Core Integration
   • Proceed with Prooph integration as before, but prioritize PHP 8.4 compatibility checks.
3. Phases 3–5: Unchanged—projections, async processing, and monitoring remain sequential.

Operational Impact

Maintenance

• Prooph-Specific Maintenance:
  • PHP 8.4 Deprecation Impact: If the app uses PHP 8.4, refactor any code relying on removed deprecations (e.g., array(), gmp_random()).
  • Schema updates and dependency management remain unchanged.
• Event Schema Evolution: Unchanged—forward/backward compatibility in projections is still required.
• Backup Strategy: Unchanged—regular backups of the event store DB are critical.

Support

• Debugging Complexity: Unchanged—event replay and concurrency issues remain potential pain points.
• Community & Documentation: Unchanged—Prooph’s community is active, but Laravel-specific gaps persist.
• Vendor Lock-in Risk: Unchanged—Prooph’s design choices may still complicate future migrations.

Scaling

• Write Scaling: Unchanged—single-writer design and write amplification risks persist.
• Read Scaling: Unchanged—projections and snapshots remain key for performance.

New Consideration Due to Release:

• PHP 8.4 Environments:
  • If the app runs on PHP 8.4, monitor for runtime warnings after upgrading Prooph.
  • Ensure CI/CD pipelines test the new version with PHP 8.4 to catch compatibility issues early.

NO BREAKING CHANGES TO ARCHITECTURE OR INTEGRATION, but PHP 8.4 users must audit for deprecated feature usage.