Doctrine Domain Events Laravel Package

Product Decisions This Supports

• Build vs. buy/borrow for domain event dispatch. The package answers a specific architectural question: where does the event actually get published? Rather than inventing an internal convention (entities return events, application service drains and dispatches after flush), this package makes Doctrine's flush the publishing boundary. That's a defensible product/architecture decision worth evaluating on its merits, independent of the package's popularity.
• Roadmap: enabling a domain-driven or modular-monolith decomposition. Domain events are the cheapest available seam for splitting a monolith into modules or services later. If the roadmap includes modularization, event infrastructure becomes a prerequisite — this package is one candidate implementation of that prerequisite, not the strategy itself.
• Sequencing side effects inside the same unit of work. The differentiating capability — calling flush from inside an event triggered by flush (re-entrant/nested flush) — maps directly to a real product behavior class: "when an aggregate changes, another aggregate must also change, atomically." Examples: order placed → inventory reservation → stock ledger entry; invoice issued → ledger posting; user onboarded → default workspace/project created. Without this, teams either duplicate flush logic in application services or accept eventual consistency where they wanted a transaction.
• Reducing coupling in cross-cutting features. Notifications, audit trails, activity feeds, webhooks, search indexing, and read-model projections are the canonical consumers. Deciding "these are event subscribers, not inline service calls" is a product-architecture decision that this package operationalizes.
• Use cases where it earns its place: event-sourced-ish aggregates with follow-on writes; audit/compliance requirements demanding immutable change records; integrations that must not leak into the domain layer; multi-step transactional workflows spanning several entities.
• Informs effort estimation and risk appetite. With 6 stars, 0 dependents, and no ecosystem validation, this is a reference implementation / decision input, not a dependency you adopt on faith. The PM decision it most directly supports is: "do we spend a sprint building this internally (roughly 300–600 lines of listener/collector code), vendor this package, or fork it?"

When to Consider This Package

Adopt (or fork) when:

• The stack is Doctrine ORM — Symfony, or Laravel running laravel-doctrine/doctrine/orm alongside Eloquent. If you are Laravel-native with Eloquent only, this package is not applicable; the equivalent decision is spatie/laravel-event-sourcing or a hand-rolled model-event dispatcher.
• You have (or expect) multi-aggregate transactional cascades — the nested-flush feature is the only real reason to prefer this over the simpler, better-supported alternatives.
• You already have Symfony Messenger / a PSR-14 dispatcher and want entities to stay free of infrastructure imports.
• You are willing to pin, vendor, or fork — treat it as source you own, not as a maintained upstream.
• You are doing a spike or PoC to compare "events on flush" vs. "events returned from aggregates" before committing an internal library.

Look elsewhere — do not adopt — when:

• You need ecosystem support and a maintenance guarantee. 6 stars, 0 dependents, a score of 0.06, and a single-maintainer bus factor are disqualifying for a critical path. MIT license means forking is cheap; relying on upstream is not.
• You only need async, post-commit reactions (emails, webhooks, cache busting). Standard Doctrine lifecycle listeners or symfony/messenger with DispatchAfterCurrentBusStamp cover this with far less risk.
• Your platform is Laravel/Eloquent-first. There is no Laravel integration surface here — no service provider, no config publication, no queue-aware dispatcher. You would be writing the glue yourself, at which point the glue is the package and you should own it.
• You require nested transactions or full event sourcing. This is dispatch plumbing, not an event store; it has no replay, no snapshotting, no stream versioning.
• You need strict transactional outbox semantics (guaranteed delivery, idempotency, at-least-once across process failure). In-memory event collection flushed with the ORM gives you at-most-once within the request; a crash after commit but before dispatch loses events.
• You cannot own the fork. If the team has no one comfortable reading Doctrine's UnitOfWork internals, the failure modes (recursive flush loops, event loss on rollback) will be expensive.

Verdict for the roadmap: evaluate, don't adopt. Timebox a 3–5 day spike against a real cross-aggregate workflow, and plan to vendor/fork the event-collection mechanics into an internal package that you control, with the nested-flush behavior explicitly documented as your own contract.

How to Pitch It (Stakeholders)

For executives — one paragraph: "This is a small, MIT-licensed library that lets our domain objects announce 'something happened' without knowing who cares, and lets those reactions participate in the same database transaction — including cascading writes that today require duplicated code in multiple places. It's not a strategy; it's a plumbing decision. The library itself is immature (six GitHub stars, no downstream users, effectively one maintainer), so the recommendation is not to take a dependency on it. The recommendation is to use it as a blueprint and spend a few days validating the pattern against one real workflow. Expected benefit: less duplicated orchestration code, cleaner module boundaries, and a credible path toward splitting the monolith later. Expected cost: roughly one engineer-week, with the option to stop after the spike."

For engineering:

• What it does: Doctrine postFlush hook that drains per-entity recorded events into a dispatcher, plus re-entrant flush support so a listener can persist further changes without recursion or transaction corruption.
• The interesting part is the nested flush problem, which is genuinely awkward in raw Doctrine and is the sole technical justification for looking at this repo.
• Risks to name out loud: event loss on rollback, recursive-flush loops, ordering guarantees, and no outbox. Do not present this as reliable messaging.
• Ask: evaluate the source against our actual cross-aggregate workflow; if the pattern holds, we own a fork with tests, or we write ~500 lines in-house. Either way, the decision is ours, not upstream's.
• Explicitly out of scope: Eloquent/Laravel users — there is no Laravel glue here, and pretending otherwise will burn the evaluation budget.