Where should you put your business logic?

A new reader wrote after landing their first Laravel job:

The hardest part for me so far is architecture. There are many ways to do the same thing, and I don’t know whether to use a service, job, event, or action.

Laravel doesn’t prescribe where to place business logic. It gives us options, which is great!

But too many choices can lead to indecision, or result in an inconsistent application architecture.

Let's start by identifying some of the main places we can put logic and how they differ:

• Controller - Logic sits in the natural flow of the request, but it can grow and get bulky fast.
• Form Request - Great for validation logic, but weird for other business logic.
• Action class - Easy to reuse across contexts, but adds another abstraction layer.
• Service class - Nice central place for shared logic, but can drift into a dumping ground for code.
• Job - Useful to offload heavy tasks, but not ideal for synchronous flows.
• Event / Listener - Great when needing to trigger multiple pieces of logic together, but makes it easy to lose sight of what logic is firing.
• Command - Perfect for scheduled tasks or command line tooling, but feels a bit out of place for web requests.

Every single one of these options could work. The key is having a pattern to your choices so you can make them with confidence.

Tomorrow I'll share how I think through these options, and distill them into a lightweight rule set that makes it easier to choose.

Here to help,

Joel

P.S. Want a second set of eyes on your project’s architecture? Book a quick call.