entity-event-handler

Entity event handlers execute side effects after Create, Update, or Delete operations by filtering events in HandleWhen and running logic outside command handlers. This keeps CQRS command logic separate from notifications, audits, and integrations triggered by entity changes.

Yes. Implement an entity event handler that filters for Created events and executes notification logic asynchronously. Side effects like emails or cross-service messages run in UseCaseEvents after the command completes, keeping handlers clean.

Use entity event handlers with async execution to call external APIs and log audit trails on Created, Updated, or Deleted events. Handlers receive request context and can load repository data, making complex integrations and side effects straightforward.

No. Entity event handlers process cross-service messaging independently after CRUD operations. Define handlers that filter by Updated events and publish messages, leaving command handlers focused on state changes only.

Handlers execute as async tasks with full request context access, allowing repository queries to load additional data needed for notifications or integrations. This supports complex workflows without blocking command execution.

Entity event handlers suit CQRS architectures where commands focus on state changes and side effects must run asynchronously. Use them for notifications, analytics, and external integrations to maintain architectural separation and avoid command handler bloat.