[General architecture] Where do you put services you create ?

There's no correct answer here. Choose names and locations that make sense to you / your team.

A simple option is to add a Services folder and then add your classes in there. For example, Services/Stripe/CreateSubscription. For some of these things you might also choose to use Jobs instead, if you like.

I have a lot of this stuff. Personally I like to structure my application by "modules", and then I have a logical place to put anything. But that does involve substantial deviation from the standard Laravel folder structure, which means more time spent setting it up.

Thanks Mike! I like that.

In which case would I prefer to work with jobs? I kept those for things that needs to work on schedules.

@MikeHopley me too!! Carry over from my c# days. C# always preaches modular design in which case very similar to pulling in packages in Laravel. Pull in a blog add a couple of use statements to link via traits and done.

@jekinney I haven't taken it quite that far myself, but I can imagine that would be even better, especially when working on multiple projects and wanting to reuse modules. :)

In which case would I prefer to work with jobs? I kept those for things that needs to work on schedules.

Personally I'm happy using Jobs synchronously too. I like thinking of Jobs as "actions" that my application can take, and I like using them in combination with Events. This seems like a tidy way to organise my project. I have an overview of the significant actions that can be taken by looking in a module's Jobs folder.

I know they are "supposed" to be used mainly for queued tasks, but I don't see why I should care. Maybe if you are working with a sufficiently sophisticated project there might be some downside in architectural purity. But that doesn't affect me at the moment.

Of course, you can go overkill with "Jobs for everything". I do often use Jobs to extract "DB update"-type logic from a controller, but not when it's just two lines of code. ;-)

You could equally well use service classes instead of Jobs. Indeed I use a combination of both (and sometimes a Job will invoke a service class). I just find that dispatching a Job from a controller is often more readable.