Eloquent Message Repository Laravel Package

Product Decisions This Supports

• Event Sourcing Architecture: Enables adoption of EventSauce (CQRS/ES) in Laravel applications, allowing teams to model domain events as first-class citizens while leveraging Eloquent for persistence.
• Build vs. Buy: Avoids reinventing a custom message repository for EventSauce, reducing development time and technical debt. The package abstracts database interactions, aligning with Laravel’s conventions.
• Roadmap for Scalability: Supports future-proofing by integrating with EventSauce’s event-driven architecture, enabling eventual consistency patterns, audit logs, and replayable event streams.
• Use Cases:
  • Audit Trails: Track immutable event history for compliance or debugging.
  • Real-Time Systems: Power event-driven notifications or syncs (e.g., WebSockets).
  • Data Reconciliation: Resolve discrepancies via event replay (e.g., financial systems).
  • Microservices: Decouple services by persisting events in a shared database.

When to Consider This Package

• Adopt if:

  • Your Laravel app uses EventSauce or plans to implement Event Sourcing/CQRS.
  • You need a simple, Eloquent-based message store without complex ORM setups (e.g., Doctrine).
  • Your team prioritizes developer velocity over custom solutions (e.g., raw SQL or NoSQL).
  • You require Laravel-native migrations and integration with Eloquent’s query builder.

• Look elsewhere if:

  • You need high-performance event storage (e.g., Kafka, Redis, or a dedicated event DB like EventStoreDB).
  • Your project requires multi-tenancy or sharding out of the box (this package assumes a single schema).
  • You’re using PHP < 8.2 or Laravel < 10 (compatibility is strict).
  • You need advanced event versioning or schema validation beyond what Eloquent provides.
  • Your team lacks familiarity with EventSauce or Eloquent, requiring significant upskilling.

How to Pitch It (Stakeholders)

For Executives:

*"This package lets us adopt Event-Driven Architecture in Laravel with minimal risk. By using EventSauce (a battle-tested CQRS/ES library) and persisting events via Eloquent (our existing ORM), we can:

• Reduce complexity: No need to build or maintain a custom event store.
• Future-proof the system: Event Sourcing enables auditability, replayability, and scalability for critical workflows (e.g., orders, payments).
• Leverage Laravel’s ecosystem: Integrates seamlessly with migrations, queues, and testing tools. Investment: Low (one Composer install + migration). ROI: Faster development, cleaner domain modeling, and easier debugging."*

For Engineering:

*"This solves a pain point for teams using EventSauce in Laravel: how to persist events without Doctrine. Key benefits:

• Simplicity: Uses Eloquent’s query builder—no new ORM to learn.
• Flexibility: Customize message tables via migrations (e.g., add tenant_id later).
• Performance: Optimized for Laravel’s DB layer (no external dependencies).
• Testing: Built-in test suite ensures reliability. Trade-offs:
• Not ideal for ultra-high-throughput systems (consider EventStoreDB if needed).
• Assumes single-tenant by default (extend with middleware if multi-tenancy is required). Next Steps:

1. Spike: Benchmark against raw SQL/Doctrine for our event volume.
2. Pilot: Use for a non-critical aggregate (e.g., notifications) before core domains.
3. Integrate with Laravel Horizon for event processing if async is needed."*