IxDF Developer Docs

Appearance

Job ​

Naming Conventions ​

Structure: VerbNoun — imperative verb describing the action (e.g., ProcessOrder, SendWelcomeEmail, GenerateReport)

php
// ✅ Good
class ProcessPayment {}
class SyncUserToMailchimp {}
class GenerateInvoicePdf {}

// ❌ Bad
class PaymentProcessor {}  // Noun, not imperative
class EmailJob {}          // Too vague, redundant "Job" suffix

Job Characteristics ​

Jobs should follow these characteristics:

  • Reentrancy — if interrupted, a job can be restarted and completed successfully
  • Idempotence — a job can be called multiple times without changing the side effects
  • Concurrence — more than one instance can run simultaneously (or use ShouldBeUnique)
  • Sequence Independence — the order doesn't matter (or use Bus::chain())

See: Matt Stauffer - Patterns That Pay Off

Dispatching ​

Use dispatch() helper instead of Dispatchable trait or Facade, as only dispatch() respects the ShouldBeUnique interface. See details.

php
// ✅ Good
dispatch(new YourJob($argument));

// ❌ Bad
YourJob::dispatch($argument);          // Uses magic and with variadic parameters https://github.com/laravel/framework/pull/58209#issuecomment-3693931660 (point 2)
Bus::dispatch(new YourJob($argument)); // Facade — doesn't respect ShouldBeUnique (see https://github.com/laravel/framework/pull/58209#issue-3761845234)

Best Practices ​

  • Keep jobs focused — single responsibility, one job per task
  • Pass IDs, not models — fetch fresh data in the job to avoid stale/serialization issues
  • Use specific queues — separate queues for different priorities (e.g., high, default, low)
  • Job classes should be final and readonly