Domain Events Bundle Laravel Package

Product Decisions This Supports

• Event-Driven Architecture (EDA) Adoption: Enables teams to implement domain-driven design (DDD) patterns by decoupling event handling from core business logic. Supports migration from procedural to event-driven workflows (e.g., order processing, inventory updates).
• Roadmap for Observability: Facilitates adding auditing, logging, or analytics without modifying entity classes (e.g., tracking entity lifecycle changes for compliance or debugging).
• Build vs. Buy: Avoids reinventing Doctrine event listener wiring, reducing boilerplate and maintenance overhead. Ideal for teams already using Symfony/Doctrine but lacking a standardized event system.
• Use Cases:
  • Real-time notifications: Trigger emails/SMS when entities are created/updated (e.g., user signups, payment confirmations).
  • Cross-cutting concerns: Centralize validation, caching, or access control logic (e.g., soft-deletes, role-based actions).
  • Microservices communication: Publish domain events to message queues (e.g., RabbitMQ) for async processing.
  • Legacy system integration: Bridge old systems with modern event handlers without rewriting core logic.

When to Consider This Package

• Avoid if:
  • Your team uses Symfony Messenger or Doctrine Extensions (e.g., Gedmo), which already handle event-driven workflows natively.
  • You need field-level granularity (e.g., "only trigger on price updates"), as this package lacks that feature (see TODO in README).
  • Production stability is critical: The bundle requires DoctrineBundle’s dev-master branch and is explicitly marked as not production-ready.
  • You’re using non-Symfony PHP or a framework with built-in event systems (e.g., Laravel’s listeners).
• Consider if:
  • You’re building a Symfony/Doctrine-based monolith or microservice and need lightweight, service-based event listeners.
  • Your team prioritizes separation of concerns (e.g., keeping business logic in entities and side effects in subscribers).
  • You lack a centralized event dispatching layer and want to avoid annotation-based listeners (e.g., @ORM\HasLifecycleCallbacks).
  • You’re experimenting with DDD and need a simple way to implement domain events without complex infrastructure.

How to Pitch It (Stakeholders)

For Executives:

"This package lets us add real-time reactions to data changes—like sending alerts or updating related systems—without slowing down our core workflows. For example, when a customer places an order, we could automatically check inventory, log the action, or notify support. It’s like plugging in new features without rewriting the foundation. The trade-off? It’s early-stage, so we’d need to validate it in a non-critical environment first."

For Engineering:

*"This bundle simplifies Doctrine event listeners by moving them to services configured in YAML. Key benefits:

• Decoupling: Business logic stays in entities; side effects (e.g., notifications) live in subscribers.
• Symfony-native: Works with existing DI and Doctrine setups.
• Flexibility: Supports all Doctrine lifecycle events (prePersist, postUpdate, etc.). Downsides: Requires DoctrineBundle dev-master (blocker for now) and lacks field-level event targeting. If we proceed, we’d need to either:*

1. Fork and extend it (e.g., add field-level triggers), or
2. Use it as a proof-of-concept and migrate to Symfony Messenger later for long-term stability."

Ask the team:

• "Do we have a use case where event listeners would reduce technical debt?"
• "Can we test this in a sandbox with our dev-master Doctrine setup?"