Domain Events Laravel Package

Product Decisions This Supports

• Feature shaping for event-driven capabilities. Domain events are the seam that lets one bounded context announce "something happened" (OrderPlaced, InvoicePaid, TrialExpired) without coupling to the consumers. This package gives engineering a consistent vocabulary for that seam, which directly enables features like audit trails, notifications, webhook fan-out, analytics pipelines, and third-party integrations — each of which is otherwise a bespoke hook bolted onto a controller.
• Build vs. buy for the eventing backbone. The package covers the modelling half of domain events (rich event objects, recording/releasing from aggregates, dispatch timing). It does not replace a broker, queue, or outbox. That distinction is the decision: adopt this as the in-process domain layer, keep the transport decision (Laravel events/queues, Symfony Messenger, an outbox table) as a separate, arguably still-open build-vs-buy call.
• Roadmap sequencing for modularisation. If the roadmap includes splitting a monolith into modules or services, domain events are the cheapest first step: they create the boundaries in-process before any network boundary exists. A package like this is a low-cost way to standardise that before teams diverge on conventions.
• Reducing integration cost per feature. Once events are first-class, adding a consumer (a new notification, a CRM sync, a data warehouse feed) becomes additive rather than an edit to the originating workflow — a measurable reduction in lead time for a recurring class of requests.
• Architecture governance. A shared event base class and naming/immutability conventions are the kind of thing that rots without a canonical implementation. This package is a cheap way to encode a standard the team would otherwise re-litigate per squad.
• Use cases that justify it quickly: transactional outbox for reliable side effects after commit, domain-level audit logging, decoupling a legacy write path from new read models, and giving QA/analytics a stable event contract to test against.

Caveat for the decision record: with 0 stars, 0 dependents, and a low opportunity score, this is not a market-validated dependency. Treat it as a reference implementation and convention set, not a strategic bet.

When to Consider This Package

Consider it when:

• You already think in domain events and are missing only the plumbing — aggregates that record events, a release/dispatch step, and dispatch-after-commit semantics tied to the transaction boundary. If your team would otherwise hand-roll this in three slightly different ways, a small MIT package is cheaper than the inconsistency.
• You want a thin, framework-honest layer. It is MIT, small-surface, and Laravel-compatible without demanding a full event-sourcing rewrite. That makes it viable for a pilot inside one module.
• You need the pattern more than the tooling. The real deliverable is the convention: immutable events, past-tense naming, no domain logic in listeners, dispatch only after the transaction commits. You can adopt the ideas and vendor the few classes you need.
• Your team is small enough to own the risk. With no dependents and a single maintainer, the failure mode is abandonment, not a security incident. If you can read ~a few hundred lines of PHP and fork it, the risk is bounded.

Look elsewhere when:

• You need delivery guarantees. No outbox, retries, ordering, or exactly-once semantics should be assumed. If the business requirement is "the invoice email must not be lost," you need a durable outbox and a queue you operate — not this.
• You need cross-service eventing. Broker, schema registry, and versioning concerns are outside its scope.
• You need event sourcing. Replay, snapshots, projections, and aggregate rehydration from a stream are a different (heavier) commitment; use an event-sourcing library or a purpose-built framework.
• Procurement demands provenance. Zero stars and zero dependents means no community signal, no third-party CVE coverage, and no ecosystem of answers. In a regulated or long-lived product, prefer an in-house 200-line abstraction you control, borrowing the package's design.
• Your stack is not Laravel/PHP, or is Laravel but already standardised on a first-party or framework-native event convention that a second one would fragment.

Adoption recommendation: pilot in one bounded context behind an internal DomainEventBus interface, pin the version, and fork if the maintainer goes quiet. Do not make it a platform dependency.

How to Pitch It (Stakeholders)

To executives (one paragraph): We are proposing a small, free, open-source building block that standardises how our application announces business events internally — an order was placed, a payment settled, a subscription lapsed. The value is not the library itself; it is that new features (notifications, audit history, partner integrations, reporting feeds) can subscribe to those announcements instead of being wired into the original workflow. That makes each subsequent integration cheaper and less risky to ship, and it is a prerequisite if we ever separate parts of the product into independent services. Cost is near zero and the code is MIT-licensed, so this is a low-cost, reversible architectural convention — not a vendor commitment. Recommended next step: a scoped pilot in one module with a clear success measure (time-to-add a new consumer), reviewed before wider rollout.

To engineering leadership: It gives us a canonical way to model domain events — immutable event objects, recording from aggregates, and dispatch after the transaction commits — so we stop re-inventing it per squad. It sits inside the domain layer and deliberately does not do transport. That means the queue/outbox/broker decision stays with us and is not foreclosed. Risk profile: single maintainer, no dependents, no release maturity. MIT license and small surface mean forking is trivial, so we should wrap it behind our own interface, pin the version, and treat the design as the durable asset rather than the dependency.

To the delivery team: You gain a shared, boring, predictable pattern for side effects and integrations, plus cleaner tests — events are plain objects you can assert on without standing up a queue. The rule we are buying is simple: record events in the domain, publish them after commit, and keep listeners free of business logic. If the package stalls, nothing about our architecture changes; we own the interface.