Domain Event Laravel Package

Product Decisions This Supports

• Build vs. buy for the eventing seam. This package is a thin layer, so the decision it really informs is "do we adopt a DDD eventing abstraction or write ~300 lines ourselves?" Quantify against Laravel's native dispatcher before committing.
• Modular monolith roadmap. It gives bounded contexts a way to publish integration events without direct coupling, which is the decision that keeps a future service extraction (or a message broker) from becoming a rewrite.
• Publish-after-commit semantics. The differentiator is deferred event release: events raised by an aggregate are held and only dispatched once the command/transaction succeeds. That decides whether "send the confirmation email" and "update the read model" can ship safely now, or need an outbox table and a broker first.
• Domain-layer independence. Aggregates record events; the domain stays framework-free. That's a decision about how long your core logic survives a Laravel major upgrade — or an extraction out of Laravel entirely.
• Feature use cases this unblocks: order lifecycle notifications, audit trails, cache and search-index invalidation, cross-module projections, eventual consistency between modules sharing one database, and idempotent consumers of internal events.
• Serialization for transport. Event classes are designed to be queued/serialized, which informs the decision to defer async integration work rather than design it in now.

When to Consider This Package

Adopt if:

• You have genuine DDD layering — aggregates that raise events, not just Eloquent model hooks.
• The transaction-boundary problem is real for you (side effects firing inside a transaction that later rolls back).
• You need events to be serializable so a queue transport can be added later without changing the domain.
• You're prepared to wrap it behind your own DomainEventBus interface so the dependency stays swappable.

Look elsewhere if:

• You just need to fire a hook after a save — Laravel model events and the native Event facade cover that with zero new concepts.
• The team isn't bought into DDD; the terminology overhead will outweigh the benefit.
• You need modern PHP 8.x guarantees, active security response, or certified Laravel 10/11 support. Last release was 2019-08-06, 18 stars, effectively a single-maintainer project — treat it as unmaintained. That's a real adoption risk, not a footnote.
• Your scale or reliability needs already justify a broker or framework (Symfony Messenger, EventSauce, Ecotone, Prooph) — don't outgrow a 2019 micro-library in six months.

Mitigation if adopted: pin the version, vendor or fork it, keep it behind an internal interface, and budget a few days to replace it in-house. The surface area is small enough that the escape hatch is cheap.

How to Pitch It (Stakeholders)

To executives: This is a free, MIT-licensed library that lets us structure feature-to-feature communication so today's modules can later become independent services without a rewrite. The license cost is zero; the real costs are engineering discipline and a maintenance risk, which we contain by wrapping it in our own interface so it's replaceable in days. Recommend a short spike, not a broad rollout, before committing roadmap capacity.

To engineering: It provides an event bus, aggregate event recording, and — the part that matters — deferred release of events after the transaction commits, which eliminates the class of bug where a confirmation email goes out and then the write rolls back. Compare honestly against Laravel's native dispatcher: the only non-trivial value is the deferred-release mechanism and the framework-free domain layer, and we could reproduce both in a few hundred lines. Given the package is unmaintained since 2019, my recommendation is to prototype with it to validate the pattern, then either vendor it or reimplement the small piece we actually need.