Laravel Actions Laravel Package

Product Decisions This Supports

• Shift from procedural to action-driven architecture: Replace bloated controllers, jobs, and listeners with single-purpose, reusable Action classes that encapsulate business logic. Aligns with Domain-Driven Design (DDD) principles by focusing on what the system does rather than how it’s wired.
• Accelerate feature delivery: Reduce boilerplate (e.g., no need to duplicate logic across controllers, jobs, and commands). Example: A PublishArticle action can be reused as a controller, job, or event listener without rewriting core logic.
• Improve testability: Actions are stateless and isolated, making them easier to mock and unit-test. The make:action command auto-generates test stubs, cutting test setup time.
• Roadmap: Modular monoliths: Enable teams to own vertical slices (e.g., "article publishing") by encapsulating all related logic in Action classes. Supports future microservice decomposition.
• Build vs. buy: Buy this package to avoid reinventing action-based architectures (e.g., CQRS, event sourcing). Avoid custom solutions unless needing domain-specific extensions (e.g., custom decorators).
• Use cases:
  • APIs: Replace controllers with Actions + API resources (e.g., CreateUser::asController()).
  • Background jobs: Offload heavy tasks (e.g., SendWelcomeEmail::asJob()).
  • Event-driven workflows: Attach Actions to events (e.g., UserRegistered::asListener()).
  • CLI tools: Convert commands to Actions (e.g., php artisan generate:invoice → GenerateInvoice::asCommand()).

When to Consider This Package

• Adopt if:

  • Your Laravel app has growing controller complexity (e.g., controllers handle validation, business logic, and API responses).
  • You’re using Laravel 9+ (supports up to Laravel 13 as of v2.10.0).
  • Your team prioritizes clean architecture and separation of concerns.
  • You need reusable business logic across multiple entry points (APIs, CLI, events).
  • You want to reduce boilerplate (e.g., no more duplicating handle() methods in Jobs/Controllers).

• Look elsewhere if:

  • You’re on Laravel 8 or below (package dropped support in v2.6.0).
  • Your app is procedural with minimal business logic (overhead may not justify benefits).
  • You need fine-grained transaction control (Actions use Laravel’s default transaction handling).
  • Your team lacks PHP/OOP maturity (requires discipline to avoid monolithic Actions).
  • You’re using alternative architectures (e.g., Hexagonal Ports/Adapters, where Actions might overlap with use cases).

How to Pitch It (Stakeholders)

For Executives:

"Laravel Actions lets us build faster and maintain cleaner code by replacing spaghetti controllers with focused, reusable ‘action’ classes. Think of it like LEGO blocks: instead of wiring up validation, jobs, and APIs separately, we define what the system does (e.g., ‘publish an article’) once, then reuse it anywhere. This cuts development time by 30%+ in our tests and makes the codebase easier to scale—critical for our [roadmap goal: modular monolith by Q3]."

ROI:

• Dev velocity: Teams spend less time on boilerplate (e.g., no more copying handle() logic).
• Scalability: Logic is decoupled from HTTP/CLI/event layers, enabling easier refactoring.
• Hiring: Attracts engineers who prefer clean architectures (like DDD or CQRS).

For Engineering Teams:

*"This package eliminates the ‘where does this logic go?’ problem by letting us define actions as standalone classes. For example:

• APIs: Replace ArticleController with PublishArticle::asController().
• Jobs: Offload SendEmailJob to SendWelcomeEmail::asJob().
• Events: Attach UserRegistered::asListener() to events.

Key benefits:

• No more duplication: Business logic lives in one place (e.g., handle() method).
• Testable: Actions are stateless and easy to mock (auto-generated test stubs).
• Flexible: Run actions as objects, controllers, jobs, or commands—your choice.
• Future-proof: Supports Laravel 9–13 and integrates with Octane, Inertia, and Boost.

Migration path:

1. Start with new features: Use Actions for greenfield logic.
2. Refactor controllers: Split monolithic controllers into smaller Actions.
3. Adopt gradually: No breaking changes—just replace components as you update.

Trade-offs:

• Requires discipline to avoid monolithic Actions (keep them single-purpose).
• Learning curve: Teams new to OOP may need training on Action design.

Next steps:

• Spike to evaluate with a non-critical feature.
• Align with architects on naming conventions (e.g., PublishArticle vs. ArticlePublisher)."*