Domain Events Bundle Laravel Package

Product Decisions This Supports

• Event-driven side effects are now transaction-safe by default. v0.4.5 stops publishing domain events while a database transaction is open. This is the behavior you want before shipping anything customer-visible that is triggered by domain events — confirmation emails, webhooks, search indexing, analytics — because it eliminates a class of "phantom" notifications fired from work that later rolls back.
• Informs build vs. buy on the event/outbox layer. If your roadmap includes reliable after-commit dispatch without hand-rolling a transactional outbox, this package now covers the core guarantee for free. Use the release as a forcing function to decide whether you standardize on this or on framework-native primitives (Laravel's DB::afterCommit / queued listeners, Symfony's kernel.terminate semantics).
• Sets a roadmap prerequisite for async and integration work. Any upcoming feature that fans out to third parties (payments, CRM sync, partner APIs) depends on exactly this guarantee. Treat v0.4.5 as a dependency to validate, not a feature to announce.
• Shifts a known reliability gap from "accepted risk" to "resolved." Prior to this release, a listener firing mid-transaction could emit an irreversible external effect that no rollback could undo. That is now mitigated without application-level changes — a cheap win to bank in the current cycle.
• Signals a maturing but still pre-1.0 dependency. A semantically significant change landing in a patch release (0.4.5) tells you the maintainer is iterating quickly on correctness and that version pinning plus an upgrade-test ritual is a product-level requirement, not an engineering nicety.

When to Consider This Package

Adopt when:

• Your domain model already emits events from inside aggregate/entity methods and you need those events to correspond to committed state, not in-flight state.
• You are about to build outbound integrations or notifications and want after-commit semantics without writing the mechanism yourself.
• You run PHP with a Symfony-style bundle stack, or you are willing to bridge it into a Laravel app and accept the integration surface that implies. Verify the container/listener wiring before committing — this is bundle-shaped, so a Laravel adoption carries glue code you will own.
• Your team is small enough that maintaining a bespoke transactional outbox is not a good use of engineering capacity.

Look elsewhere when:

• You need durable, at-least-once delivery. "Prevents publishing during a transaction" is not the same as "persists the event and guarantees eventual dispatch." If an event is dropped rather than deferred until commit, this is not an outbox and you still need one (or a message broker with a real outbox pattern).
• You require strict ordering or replay of domain events, or cross-process delivery.
• You are on Laravel and standard framework facilities (ShouldQueue + afterCommit, DB::afterCommit) already satisfy the requirement — buying a Symfony bundle to get framework-native behavior is negative value.
• Your listeners have immediate-read-after-write expectations. Deferring dispatch to commit changes observable latency, and any listener that reads its own writes mid-request may now break.

Immediate verification item: confirm whether events raised inside a transaction are queued until commit or silently discarded. The release note is ambiguous, and the two behaviors have materially different product consequences — one is a latency change, the other is data loss. Do not ship on the assumption.

How to Pitch It (Stakeholders)

For executives: A dependency update closed a real integrity hole. Previously, a failed database operation could still trigger customer-facing side effects — emails, partner notifications, downstream records — that could not be undone. The library now withholds domain events until the surrounding transaction is safely committed, so failed operations stay silent. This is one patch release, no migration work, and it de-risks the integrations on our roadmap. Cost is a regression test pass, not a project.

For engineering: v0.4.5 changes dispatch timing — events no longer fire while a transaction is active. That is the correct default, but it is a behavioral change shipped in a patch version, so treat it as breaking in practice. Two things to do before merge: (1) read PR #46 and determine whether in-transaction events are deferred to commit or dropped, and (2) audit every listener for immediate-read-after-write assumptions and for any code that relied on mid-transaction dispatch. Add an explicit regression test asserting that a rolled-back transaction produces zero external side effects. Pin the exact version; this package is pre-1.0 and the maintainer is actively changing semantics.