Entities Events Bundle Laravel Package

Product Decisions This Supports

• Event-Driven Architecture (EDA) Adoption: Enables seamless integration of event-driven workflows into Symfony applications, reducing tight coupling between components. Ideal for systems requiring real-time notifications, workflow automation, or microservices communication.
• Decoupling Business Logic: Facilitates separation of concerns by allowing entities to emit events (e.g., UserCreatedEvent) while listeners handle side effects (e.g., sending welcome emails, logging, or triggering downstream services).
• Roadmap for Scalability: Supports incremental feature rollouts by enabling event-based extensions (e.g., analytics, auditing) without modifying core entity logic.
• Build vs. Buy: Buy for teams already using Symfony/Doctrine; build only if needing custom event dispatching logic beyond Symfony’s native EventDispatcher.
• Use Cases:
  • Audit Trails: Automatically log entity changes (e.g., UserUpdatedEvent → database audit table).
  • Notifications: Trigger emails/SMS when entities are created/updated (e.g., OrderShippedEvent → send tracking info).
  • Workflow Automation: Chain events to orchestrate complex processes (e.g., PaymentProcessedEvent → update inventory).
  • Third-Party Integrations: Sync data with external APIs (e.g., ProductUpdatedEvent → push to Shopify).

When to Consider This Package

• Adopt if:

  • Your Symfony app uses Doctrine ORM and needs event-driven entity lifecycle hooks (create/update/delete).
  • You want to avoid manual event dispatching in repositories/services (e.g., entityManager->persist($entity); $dispatcher->dispatch(...)).
  • Your team prioritizes decoupled architecture and testability (events can be mocked/stubbed easily).
  • You’re using Symfony 6/7 + PHP 8.2+ and already have EventDispatcher in your stack.

• Look Elsewhere if:

  • You’re not using Symfony/Doctrine (e.g., Laravel, custom ORM, or raw SQL).
  • You need real-time event streaming (consider Mercure, RabbitMQ, or Laravel Echo).
  • Your events require complex async processing (e.g., long-running tasks; use Symfony Messenger or Laravel Queues instead).
  • You lack developer resources to maintain custom event listeners (this package adds boilerplate for setup).
  • The archived status concerns you (though MIT license allows forks; evaluate risk vs. alternatives like Symfony’s native EventDispatcher).

How to Pitch It (Stakeholders)

For Executives:

"This package lets us build a more flexible, scalable Symfony backend by automatically triggering actions (like notifications or audits) whenever data changes—without tightly coupling our code. For example, when a user signs up, we can instantly send a welcome email, log the action, and sync with our CRM—all without modifying the core user-creation logic. It’s a low-code way to add event-driven features, reducing development time and improving maintainability. The MIT license means no vendor lock-in, and it integrates cleanly with our existing Symfony stack."

For Engineers:

*"This bundle abstracts away the boilerplate of manually dispatching events for Doctrine entity lifecycle hooks (prePersist, preUpdate, etc.). Instead of sprinkling $dispatcher->dispatch() calls across repositories, we:

1. Annotate entities with HasEventsInterface (1 line of code).
2. Generate listeners via CLI (php bin/console atournayre:entities-events:generate-listeners).
3. Write listeners as simple classes (e.g., #[AsEventListener]). Key benefits:

• Cleaner entities: No event logic cluttering business methods.
• Reusable events: Define once (e.g., UserEvent), reuse across listeners.
• Symfony-native: Uses EventDispatcher and Doctrine events under the hood. Trade-offs: Adds a small dependency (MIT-licensed, archived but functional). For teams already using Symfony, this is a 50% time savings on event-driven features compared to rolling our own solution."*