Simple rules for where to put business logic

Yesterday, I shared the common places to put business logic in your Laravel app.

So how do you pick which one to use?

Today I'll share some questions I consider when deciding where to put a new piece of business logic.

Will this run in more than one context?

If the answer is yes, I lean toward a service class. It makes it easy for controllers, jobs, and commands to use the same logic.

An action class could be a good option as well, but it's not something I bring into my projects.

Does it need to run asynchronously?

If the work is slow or non-critical, I wrap it in a job, which can then be queued. This keeps the response snappy for the end user.

Is the logic in response to a specific trigger?

For example, it happens every time a certain model is created or updated. When multiple parts of the system need to know something happened, I fire an event and handle the particular logic in the listeners that are wired up.

But I exercise caution here to not bury too much logic behind the scenes.

That’s the core checklist. And if none of them apply, I default to keeping the logic in the controller.

As my app grows and evolves, I continue to revisit these decisions. Maybe something was only used in one place to start, but later that expands to two or three. Now is the time to extract the logic from a controller and move it somewhere else.

Also, please note I'm providing these questions to consider, but I'm not prescribing the exact answers. You will need to decide what makes sense for your project and team.

Your answers might differ from mine, and that’s fine. The goal is to think through the process, make your reasoning consistent, get agreement with your teammates, and then keep it in mind as you build your app.

Here to help,

Joel

P.S. The next time you're struggling with a problem, don't forget that the community and Get Unstuck sessions are here to help you out.