Domain Event Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for the domain layer. This package is a candidate answer to "who owns our aggregate-root event plumbing?" It bundles event recording inside entities, collection of raised events, and dispatch — roughly the 150–300 lines of glue most teams rewrite anyway. The real decision it informs is whether to standardize that glue or let each team roll its own.
• DDD adoption sequencing on the roadmap. If the roadmap item is "introduce tactical DDD patterns," this is a cheap probe of whether aggregate-raised domain events actually earn their place in your codebase before you commit to a heavier framework (EventSauce, Prooph, Spatie event sourcing).
• Sync vs. deferred dispatch policy. The package's core value is separating "an aggregate state change happened" from "the side effect now runs." That directly supports product decisions about in-request side effects (notifications, audit records, cache invalidation) versus deferred/queued work, and where transaction boundaries sit.
• Audit trail and cross-context decoupling feature work. Any roadmap item requiring "record every meaningful business fact" or "let Billing react to Order without Order importing Billing" is a use case this pattern serves — and a reason to evaluate the pattern even if you reject the package.
• Evidence for a reject-and-write-in-house decision. 14 stars, 0 dependents, no release since May 2021, and a composite score of 0.23 are themselves decision inputs: they justify closing the "adopt an external domain-event library" question and funding a small internal module instead.

When to Consider This Package

Adopt only if all of these hold:

• You are on Symfony, not Laravel. Despite being catalogued as a Laravel/PHP package, this is a Symfony bundle — it expects bundle registration, the Symfony DI container, and kernel wiring. There is no Laravel service provider, facade, or config publish path.
• You are doing tactical DDD with real aggregate roots and want events raised inside the domain, released only after persistence succeeds.
• You are comfortable owning the source. With one maintainer and a 2021 last release, treat this as vendored code you may need to patch for PHP 8.x and future Symfony majors.
• You want a small, readable, MIT-licensed reference implementation to fork or imitate rather than a runtime dependency.

Look elsewhere if:

• You're on Laravel. Use the framework's dispatcher with a small RecordsDomainEvents trait plus DB::afterCommit, or evaluate spatie/laravel-event-sourcing if you need persistence and replay.
• You need delivery guarantees. No transactional outbox, at-least-once delivery, event store, or replay semantics. For distributed or cross-service work, look at Symfony Messenger with an outbox, EventSauce, or Prooph — or a broker-backed approach.
• You need support, security response, or an SLA. Zero dependents means zero downstream pressure to fix things; there is no community to lean on.
• You only need model lifecycle hooks. Eloquent observers or Symfony Doctrine listeners already cover that with no new dependency.
• You want an event bus and command bus too. The sibling gpslab/* packages share the same maintenance profile; adopting the family compounds the risk rather than diversifying it.

How to Pitch It (Stakeholders)

To executives: This is a evaluate-and-likely-reject, not a procurement. It costs roughly one engineer-week to spike, has a near-zero licensing cost (MIT), and an unusually low exit cost because the surface area is small and the code is readable. The strategic risk is dependency abandonment, not price: one maintainer, no release in over four years, no downstream users. Recommendation: approve a timeboxed spike to validate the pattern, and pre-commit to either forking the ~small codebase internally or building an equivalent module. Do not list it as a platform dependency on the architecture roadmap.

To engineering: It solves a real problem — raising domain events inside aggregates and dispatching them after the transaction commits — with a clean, minimal API. But it is Symfony-only, unmaintained since 2021, and used by no one public, so expect to own PHP and framework compatibility yourself. Proposed path: one-week spike on a single bounded context, measure how much glue it actually removes versus a 200-line in-house trait, and decide fork-versus-build. Success looks like deleting duplicated dispatch code and eliminating at least one cross-module import; failure looks like us patching a bundle we didn't want to maintain.