Domain Event Dispatcher Laravel Package

Product Decisions This Supports

• Event-Driven Architecture (EDA) in DDD: Enables clean separation of domain logic and side effects (e.g., notifications, analytics, or workflows) by dispatching events from domain models. Aligns with DDD’s principle of encapsulating behavior within domain objects while delegating cross-cutting concerns to listeners.
• Decoupled Components: Facilitates loose coupling between producers (domain models) and consumers (services, APIs, or external systems) of events, reducing direct dependencies and improving modularity.
• Build vs. Buy: Justifies a lightweight, custom-built solution over heavier frameworks (e.g., Laravel Events) if the team prioritizes simplicity, minimal overhead, or specific singleton-based dispatching patterns.
• Legacy System Integration: Useful for incrementally adopting event-driven patterns in monolithic PHP/Laravel applications without rewriting core logic.
• Roadmap for Scalability: Supports future-proofing by enabling asynchronous event handling (e.g., via deferred dispatch) or integration with message queues (e.g., RabbitMQ, Redis) if the package evolves or is extended.

When to Consider This Package

• Avoid if:

  • Modern Laravel Ecosystem: The project already uses Laravel’s built-in Event System, which is actively maintained, feature-rich (e.g., async support, broadcasting), and integrates seamlessly with queues/jobs.
  • Need for Scalability: Requires advanced features like event batching, retries, or distributed event sourcing—this package lacks modern tooling (e.g., no queue support, last updated in 2016).
  • Type Safety or Modern PHP: Relies on __invoke() magic methods and lacks PSR-15 (Middleware) or PSR-14 (Event Dispatcher) compliance, which are industry standards for event handling.
  • Team Familiarity: The team is unfamiliar with DDD or singleton patterns, as this package abstracts little and assumes domain-driven design expertise.
  • Alternatives Exist: Consider Laravel’s Events (for Laravel projects), Symfony’s Messenger (for PHP generally), or DomainEvent (a more maintained DDD-focused package).

• Consider if:

  • Greenfield DDD Project: Building a domain-driven app from scratch in PHP/Laravel where event dispatching is a core requirement and the team prefers minimalism over Laravel’s built-in system.
  • Singleton Dependency: Explicitly need a singleton dispatcher for models (e.g., to avoid passing event dispatchers as dependencies).
  • Legacy Codebase: Integrating events into an existing codebase where Laravel’s Event system is overkill or conflicts with existing architecture.
  • Learning/Prototyping: Experimenting with DDD patterns without committing to a full framework integration.

How to Pitch It (Stakeholders)

For Executives: "This package lets us implement event-driven architecture in our domain models—decoupling core logic from side effects like notifications or analytics. It’s a lightweight, PHP-native solution that aligns with Domain-Driven Design (DDD), reducing complexity in our services and making them easier to scale or replace. Think of it as a ‘fire-and-forget’ mechanism for domain events: when something important happens in our business logic (e.g., an order is placed), we can trigger actions elsewhere without tightly coupling those systems. It’s a strategic enabler for modularity and future-proofing our architecture."

For Engineering: *"The DomainEventDispatcher is a singleton-based event bus for PHP/Laravel that lets us dispatch events from domain models directly. Key benefits:

• Simplicity: No need for Laravel’s full event system if we want a minimal, DDD-focused approach.
• Singleton Access: Avoids passing dispatchers as dependencies to models (cleaner design).
• Flexibility: Listeners can be any callable with __invoke(), so we’re not locked into interfaces.
• Lightweight: Zero dependencies beyond PHP, and it’s battle-tested in DDD contexts.

Trade-offs:

• No Async/Queue Support: Events fire synchronously; we’d need to extend it for queues (e.g., via Laravel’s queue system).
• Outdated: Last updated in 2016, so no PHP 8+ features or modern standards (PSR-15).
• Laravel Integration: If we’re using Laravel, its built-in event system is more feature-rich (e.g., broadcasting, middleware).

Recommendation: Use this for prototyping or greenfield DDD projects where we want to avoid Laravel’s event system. For production Laravel apps, prioritize Laravel’s native events or Symfony’s Messenger. If we proceed, we’ll need to:

1. Extend it for async dispatch (e.g., via Laravel queues).
2. Add tests for edge cases (e.g., listener failures).
3. Document its limitations clearly for the team."*