Laravel Actions Laravel Package

Product Decisions This Supports

• Architectural Shift from Controllers to Domain-Driven Actions: Adopt a task-centric design where logic is organized by what the application does (e.g., PublishArticle, ProcessPayment) rather than by HTTP layers or event types. This aligns with Domain-Driven Design (DDD) principles and reduces boilerplate (e.g., no need to duplicate logic in controllers, jobs, and listeners).

• Accelerate Feature Delivery:

  • Build vs. Buy: Avoid reinventing middleware, validation, or job wrappers. The package provides pre-built decorators for controllers, jobs, listeners, and commands, reducing dev time by 30–50% for CRUD-heavy apps.
  • Roadmap: Prioritize features like asynchronous workflows (e.g., asJob) or event-driven actions (e.g., asListener) without coupling to Laravel’s traditional patterns.

• Use Cases:

  • APIs/Backend Services: Replace bloated controllers with lean actions (e.g., CreateUser, GenerateReport).
  • Event-Driven Systems: Consolidate logic for events like OrderPlaced into a single ProcessOrder action.
  • CLI Tools: Convert commands into reusable actions (e.g., BackupDatabase).
  • Testing: Simplify mocking by running actions directly (e.g., Action::run($params)).

• Tech Debt Reduction:

  • Unify Validation: Centralize validation logic in handle() instead of scattering it across FormRequests and controllers.
  • Decouple Concerns: Isolate business logic from HTTP/queue layers, making it reusable across contexts (e.g., a SendEmail action used in both controllers and jobs).

When to Consider This Package

Adopt When:

• Your Laravel app has repetitive boilerplate (e.g., duplicate validation, job wrappers, or controller logic).
• You’re building a domain-rich app (e.g., SaaS, e-commerce) where actions map to business workflows (e.g., FulfillOrder, RefundPayment).
• You need faster iteration on features without worrying about Laravel’s traditional layering (controllers → services → repositories).
• Your team struggles with testability due to tightly coupled controllers or jobs.
• You’re using Laravel 11+ and want to future-proof your architecture.

Look Elsewhere If:

• Your app is procedural or CRUD-light (e.g., a simple blog with 5 routes). Overhead may not justify the shift.
• You rely heavily on legacy monolithic controllers with deep middleware chains or complex inheritance.
• Your team lacks PHP/OOP maturity to adopt a task-focused paradigm (requires discipline to avoid "god actions").
• You need real-time features (e.g., WebSockets) where Laravel’s traditional event/listener model is already optimized.

How to Pitch It (Stakeholders)

For Executives:

"Laravel Actions lets us build faster and maintain cleaner code by focusing on what the app does—not how it’s wired together. For example, instead of writing separate controllers, jobs, and listeners for ‘publishing an article,’ we define one PublishArticle action that works everywhere. This cuts development time by 30–50% for new features, reduces bugs from duplicated logic, and makes the codebase easier to scale. It’s like using LEGO blocks instead of soldering circuits—we assemble workflows quickly and reuse them anywhere."

ROI Highlights:

• Faster Hires: Junior devs can contribute to business logic without mastering Laravel’s layering.
• Lower Cost: Eliminates custom middleware/job wrappers (no need to "build" what’s already provided).
• Future-Proof: Aligns with modern Laravel (11+) and PHP best practices.

For Engineering Teams:

*"This package eliminates boilerplate by letting us define actions as pure PHP classes (e.g., class CreateInvoice { ... }) and reuse them as controllers, jobs, listeners, or CLI commands. Key wins:

• No more duplicate validation: Centralize rules in handle().
• Testable by design: Run actions directly in tests (Action::run()).
• Flexible execution: One action can trigger via API, event, or cron.
• Laravel 11+ ready: Supports Octane, queues, and new features out of the box.

Migration Path:

1. Start with one feature (e.g., user signup) and refactor its controller/job into an action.
2. Use php artisan make:action to scaffold new workflows.
3. Gradually replace controllers with invokable actions (e.g., Route::post('/signup', CreateUser::class)).

Trade-offs:

• Requires discipline to avoid "god actions" (keep handle() focused).
• Initial refactor may need CI/CD adjustments (e.g., testing strategies).

Try it on a new feature first—if it saves 2+ hours per endpoint, it’s worth adopting."*