Domain Events Laravel Package

Product Decisions This Supports

• Feature velocity and change surface. A domain-event seam lets the team ship notifications, webhooks, analytics, audit logs, search indexing, and third-party syncs as listeners instead of inline code inside use cases. Every subsequent feature touches less core logic, which is a compounding roadmap benefit rather than a one-off win.
• Roadmap sequencing. If the 2–4 quarter horizon includes async processing, external integrations, or carving the monolith into bounded contexts, domain events are the seam that makes those moves cheap later. Standardizing the convention now avoids a rewrite when the pressure arrives.
• Build vs. buy vs. borrow. At 8 stars, 0 dependents, single-vendor MIT, this is a borrow-or-fork decision, not a purchase. Three viable PM calls: (a) adopt as a dependency, (b) vendor the source into our repo, (c) reimplement the pattern internally — a recording contract, a release-on-commit hook, and a bus interface. For something this small, (c) is usually the highest-value call and removes the dependency risk entirely.
• Use cases worth scoping now: user lifecycle (signup, verification, churn), subscription/entitlement changes, billing events, audit-trail requirements, and cross-context notifications.
• A decision the PM must force, not the package: sync vs. async delivery, failure semantics, idempotency, and event versioning. The package provides the plumbing; it does not answer these, and shipping without answers creates silent consistency bugs later.
• Important framing correction for the decision record: the artifact is the "Lingoda Domain Events Bundle" — a Symfony bundle wired to Doctrine lifecycle hooks. The description claims Laravel integration, but the technical evaluations conclude it is not a drop-in for a conventional Laravel/Eloquent codebase. For a Laravel product this is reference material for a design standard, not a dependency purchase.

When to Consider This Package

Adopt (as a dependency) when:

• The stack is Symfony + Doctrine and you want a thin, opinionated convention for recording aggregate events and releasing them after flush.
• You want a shared naming/payload/dispatch standard across teams without pulling in a full event-sourcing framework.
• You are willing to vendor or pin it and accept that upstream maintenance is a single originating team's goodwill.

Adopt as a pattern (fork or reimplement) when:

• You are on Laravel — use Event::dispatch inside DB::afterCommit() or a transaction callback, plus an internal RecordsEvents contract and a DomainEventBus interface. Same design value, zero dependency risk; roughly 1–3 engineering days.
• You want the seam now but are not ready to own a third-party upgrade treadmill. Wrap it behind your own interface so no domain code references vendor namespaces.

Look elsewhere when:

• You are Laravel + Eloquent only — the hard prerequisite is Doctrine persistence hooks; native model events and observers cover most of this ground.
• You need guarantees this package almost certainly does not provide: a transactional outbox table, at-least-once delivery, replayable event store, schema versioning, or dead-letter handling. Those are infrastructure decisions, not a bundle.
• You need vendor support, SLAs, security patching, or a hiring signal. Eight stars and zero dependents means no ecosystem, no Stack Overflow corpus, no community.
• You are evaluating event sourcing or CQRS proper — this is a notification pattern, not an event store.

Due diligence before sign-off: read the source (small enough to review in an afternoon), confirm whether events are persisted to an outbox or only buffered in memory until flush — the latter loses events silently if the process dies between commit and dispatch — verify PHP/framework/Doctrine version support is CI-enforced, and check release cadence over the last 6–12 months rather than a single recent release date.

How to Pitch It (Stakeholders)

To executives. This is a free, MIT-licensed convention layer for publishing "something happened" signals from inside the codebase. It is not a platform purchase: the cost is a few engineering days, and the payoff is that future features — notifications, integrations, audit trails — plug in without editing core business logic. The material risk is vendor abandonment, given a single originating maintainer and effectively zero external adopters; we neutralize that by vendoring the code or reimplementing the pattern internally. Recommendation: adopt the pattern, not the dependency — unless we are already running Symfony + Doctrine, in which case adopting the package is reasonable and the effort is trivial.

To engineering. Small surface area, MIT licensed, easy to fork. It gives us a standard recording contract on aggregates and a release-after-commit path so listeners stay out of use cases — the correct DDD shape. Two concrete cautions: (1) the artifact is a Symfony bundle built on Doctrine lifecycle hooks, so on Laravel we replicate the interface internally and back it with the native dispatcher plus DB::afterCommit; (2) it is not a transactional outbox — we must explicitly decide sync vs. async delivery, idempotency keys, listener error isolation, and event versioning ourselves, and add observability around the release hook. Budget one engineer as de facto owner if we take the dependency path.