Event

Naming Conventions

Structure: Subject + PastTenseVerb (e.g., OrderPaid, UserCreated)

// ✅ Good
class OrderPlaced {}
class OrderShipped {}

// ❌ Bad
class OrderPlacedEvent {}  // Don't add "Event" suffix
class PlaceOrder {}        // Use past tense, not imperative

For "before" events (allowing listeners to modify/prevent the action), use present continuous:

class OrderProcessing {}   // Before
class OrderProcessed {}    // After

Minimize the number of traits

By default, Laravel adds few traits to a new Event class, even if it’s unnecessary in your particular case. We fixed it in our custom stub file for Event, but it’s still better to control traits more explicitly.

-use Dispatchable, InteractsWithSockets, SerializesModels;
+use SerializesModels; // only if the Event will be used with Queued Event Listeners

• Dispatchable is to add static methods to for event dispatching, like new OrderPlaced()::dispatch().
  • By IxDF conventions, we do not use this syntax, so we don’t need this trait. Please use Event facade instead, e.g. \Illuminate\Support\Facades\Event::dispatch(new YourEvent()).
• SerializesModels is to gracefully serialize any Eloquent models if the event object contains Eloquent models and going to be serialized using PHP's serialize function, such as when utilizing queued listeners.
• InteractsWithSockets is for broadcasting only, e.g. using Laravel Echo.

Best Practices

• Use business language — name events using domain terms, not technical ones (OrderPaid not PaymentRecordInserted)
• Include all needed context — pass data listeners need; don't make them fetch extra data
• Keep events simple — events are data carriers, no business logic
• Dispatch after success — dispatch after the action completes, not before
• One event per action — don't combine unrelated changes into one event
• Event classes should be final and readonly