Weave Code
Domain Events Bundle Laravel Package
headsnet/domain-events-bundle
Symfony bundle for domain events: define and dispatch events from your domain, register subscribers, and defer delivery until after Doctrine transactions commit, keeping business logic decoupled from infrastructure.
DDD Domain events for Symfony
Frequently asked questions about Domain Events Bundle
- Can I use headsnet/domain-events-bundle in a Laravel application?
- No, this is a Symfony bundle that hooks into the Symfony kernel and Doctrine lifecycle, not a Laravel package. Laravel already provides native after-commit dispatch through ShouldDispatchAfterCommit, per-listener $afterCommit, and DB::afterCommit(). For Laravel services, borrow the pattern rather than installing Symfony and Doctrine components alongside the framework.
- How does headsnet/domain-events-bundle dispatch domain events after Doctrine flush?
- The bundle lets Doctrine entities record domain events, then collects those events and dispatches them through Symfony's EventDispatcher after the entity manager is flushed. That decouples event publishing from persistence and keeps side effects out of your entities. In 0.4.5 and later, events raised inside an active transaction are held until commit rather than dispatched immediately.
- Does version 0.4.5 change when domain events are dispatched?
- Yes. Version 0.4.5 includes PR #46, which changes dispatch timing so events raised inside an active transaction are released on commit instead of immediately. Because the package is pre-1.0, semver does not protect you from behavioral changes in patch releases. Pin exact versions and review release notes before upgrading.
- What happens to domain events if a Doctrine transaction rolls back?
- The release note does not document rollback behavior, so treat it as unverified. The intended behavior for most domain events is that events held during a rolled-back transaction are discarded, but that is wrong for audit trails or outbox writes that must be recorded regardless of outcome. Write a regression test against your Doctrine setup before relying on either outcome.
- How are nested transactions and savepoints handled by this bundle?
- Nested transactions and savepoints are not addressed in the release note, and they are a classic failure surface for deferred dispatch. You need to test how the bundle detects the active transaction and whether savepoint rollbacks release or discard buffered events. Do not assume ORM-managed transaction behavior carries over to DBAL-level or manually opened transactions.
- Is there an opt-out to dispatch a domain event immediately instead of after commit?
- There is no documented per-event or per-listener opt-out for immediate dispatch in 0.4.5. If you depend on listeners running inside the transaction, verify the source or stay on 0.4.4 while you characterize the change. Do not assume you can selectively keep the old behavior without testing.
- How do I install and configure headsnet/domain-events-bundle in Symfony?
- Install with Composer using composer require headsnet/domain-events-bundle, then enable the bundle in your Symfony application's config/bundles.php. It integrates with Symfony's DI container and EventDispatcher, and any bundle configuration is specific to Symfony rather than Laravel. For Laravel applications, there is nothing to configure because this bundle is not the right integration path.
- What Laravel primitives replace this bundle's deferred dispatch behavior?
- In Laravel, implement ShouldDispatchAfterCommit on events that must not fire on rollback, set public $afterCommit on listeners where appropriate, and use DB::afterCommit() for closures. These primitives give you deferred publishing with framework-level support and no extra dependency. They also avoid pulling Symfony and Doctrine components into a Laravel app.
- How should I test deferred domain event behavior before upgrading?
- Cover at least four paths: successful commit, rollback, nested transaction or savepoint, and dispatch with no active transaction. Assert not only that listeners ran, but when they ran relative to the transaction and whether ordering changed. Also test any manually opened DBAL transactions or non-Doctrine transaction managers your Symfony services use.
- Is headsnet/domain-events-bundle maintained and safe for production?
- Treat it as pre-1.0 software: 0.4.x patch releases can carry semantic changes, and 0.4.5 did. Pin exact versions, check PHP, Symfony, and Doctrine constraints, and confirm the maintainer's release practice before production use. For Laravel production services, use the framework's native after-commit primitives instead of adopting this bundle.
Weaver
How can I help you explore Laravel packages today?