Refactor Laravel Business Logic with Action Classes for Cleaner Architecture

When discussing application architecture, a classic question arises: where should a piece of code reside? Because Laravel is a highly flexible framework, answering whether business logic belongs in the Model layer, the Controller layer, or elsewhere is not straightforward.

If an application has only a single entry point, placing business logic in the Controller can work, but most real‑world scenarios involve multiple entry points invoking the same functionality.

For example, user registration typically involves a controller that returns a view, but a mobile client may require a JSON API, and developers often use Laravel’s artisan command to create users during early development stages. Duplicating this logic across controllers quickly becomes redundant, especially when adding features like email notifications.

The common answer on forums is to introduce a service layer and call a service class from the controller. However, designing service classes can be tricky: should you create a monolithic UserService handling all user‑related logic, or split responsibilities further?

Relying on a single model or a massive service class leads to problems as the application grows. For instance, creating a user may also require creating a related blog, which would necessitate a BlogService injected into UserService. As more features are added, dozens of service classes can end up depending on several others, resulting in tangled, redundant code.

To avoid these pitfalls, the article proposes using action classes . An action class should have a descriptive name (e.g., CreateOrder, ConfirmCheckout), expose a single public method such as handle() or execute(), remain agnostic of HTTP requests and responses, be able to depend on other action classes, and signal errors by throwing exceptions.

As a concrete example, the CreateUser action class refactors the registration process. The controller simply invokes this action, keeping both API and web routes clean and consistent.

Action classes can be nested: a bulk‑import action can iterate over a collection and call CreateUser for each record, returning a collection of newly created users while handling duplicate email cases gracefully.

For cross‑cutting concerns like logging, the decorator pattern can be applied. A LogCreateUser decorator wraps the original CreateUser action, and Laravel’s IoC container binds the decorator to the original class, allowing logging to be enabled or disabled via configuration in AppServiceProvider.