Doctrine Domain Events Laravel Package

Product Decisions This Supports

• Transactional consistency of business events. This package lets Doctrine entities record domain events that are only released after the unit of work is flushed/committed. That directly supports decisions about features where a downstream action (send email, call payment provider, push to a queue, trigger a webhook, write an audit record) must not fire if the database transaction rolls back.
• Build vs. buy for domain-event plumbing. Rather than hand-rolling a per-entity event collector, a postFlush dispatcher, and rollback handling, the team can adopt a small MIT library. This is a classic "small utility, low differentiation" decision: buy/adopt unless the team already has a mature custom implementation.
• DDD / hexagonal architecture adoption. It supports a roadmap decision to give certain bounded contexts rich domain entities that raise events (e.g., OrderPlaced, PaymentCaptured, InventoryReserved) while keeping the domain layer independent of the framework's event dispatcher. Useful where the product is moving from anaemic CRUD models toward domain models.
• Choosing Doctrine for a bounded context. Because this is Doctrine-specific, it is relevant when deciding whether a new bounded context should use Doctrine ORM rather than Eloquent. It is a supporting argument for teams that want Doctrine's unit-of-work semantics for complex domains.
• Use cases to prioritise: order lifecycle and fulfilment, payment capture and refunds, inventory reservation, subscription/billing state changes, audit logging, outbound webhook delivery, and foundational work for a future transactional outbox or event-driven integration.
• Risk and sequencing decisions. With 4 GitHub stars and 0 dependents, the PM should treat adoption as a spike-then-wrap decision: prove it in one bounded context, wrap it behind an internal interface, and keep the option to fork or replace.

When to Consider This Package

Consider it when:

• The codebase uses Doctrine ORM (typically Symfony or a Doctrine-based PHP service), not Laravel's Eloquent.
• You have (or want) rich domain entities that need to raise events, and you want those events dispatched only after a successful flush/commit.
• You need to prevent "ghost events" — notifications or side effects firing for transactions that later roll back.
• You want a small, focused, MIT-licensed dependency rather than a framework-sized event-sourcing platform.
• The team is comfortable owning integration and testing of a low-adoption library, and is willing to wrap it behind an internal abstraction.

Look elsewhere when:

• The application is Eloquent/Laravel-first — this package will not integrate with Eloquent's lifecycle. Laravel's DB::afterCommit() and model events, or a custom observer, are the natural fit.
• You need a durable transactional outbox (events persisted to a table and relayed by a worker, surviving process crashes). This library dispatches in-process; it is not a replacement for an outbox pattern with at-least-once delivery.
• You need strong community support, documentation, and a maintenance guarantee. Four stars and zero dependents is a genuine adoption risk; assume you may need to fork.
• Your events must be replayable, ordered, or delivered across service boundaries — that is messaging infrastructure (Symfony Messenger, a broker, an outbox relay), not this package.
• The team already has a tested, working custom domain-event collector; migrating for its own sake is not justified.

How to Pitch It (Stakeholders)

For executives (one paragraph). This is a small, free (MIT) open-source library that helps keep business events consistent with database changes: if a transaction rolls back, the corresponding notification, payment call, or webhook is not sent. It reduces a class of "phantom action" bugs in complex flows such as orders and payments, at effectively zero licence cost. The trade-off is low adoption — four stars and no known dependents — so we would prove it in one bounded context, wrap it behind our own interface, and retain the ability to fork or replace it. Recommendation: approve a short, time-boxed spike, not a broad rollout.

For engineering. It plugs into Doctrine's flush lifecycle so entities can record domain events that are released after commit, keeping the domain layer free of dispatcher concerns. Integration surface is small and the licence is permissive, so lock-in is low. The main diligence items are: (1) confirm flush/commit semantics and rollback behaviour against our Doctrine version and transaction boundaries, (2) decide on a wrapper interface so the dependency is replaceable, (3) add tests covering rollback, nested transactions, and events raised but not flushed, and (4) document that this is in-process dispatch, not a durable outbox — any at-least-once requirement needs a separate mechanism.

Ask. A one-sprint spike in a single bounded context, with a go/no-go review against explicit criteria: correct commit/rollback behaviour, no measurable performance regression, acceptable maintenance burden, and a clean wrapper boundary.