Add guide for where to put service classes

[sallyhall]

Distilled from a slack conversation about where to put service classes

[JoelQ]

Potentially relevant prior art:

• Document app/services #578
• Add best practices about Service Objects #402

[jferris]

Thanks for distilling this! I have a few thoughts:

• Should this be two bullets? (One about lib/ and one about app/jobs)
• Maybe something like "Use lb/ for code that will later be extracted to a gem" to describe lib? I think it could be anything generic, it's hard to make a finite list. My opinion is that lib/ shouldn't have app-specific code.

[thiagoa]

Looks good to me. About jobs, I think they should, ideally, be thin wrappers over existing services -- but that is an optimization that can be gradually applied as needed. I've always found a tension between moving code between services and jobs, and in the end I think that distinction is not so important. Code that runs synchronously should also be able to run async.

Also, when the app reaches a certain complexity threshold, I prefer extracting concepts and trashing most of the extra non-MVC categorization -- where some of these guidelines would not apply. Otherwise, I think the "Rails way" of structuring code works.

With the app/services, app/jobs, etc, arrangement you're always forced to put things in buckets, and app/models is usually the trash folder for code that doesn't have a category.

If you structure code in a certain way, its category becomes less important. For example, it's clear that this represents a service: app/concepts/sales_tax/calculate_sales_tax, and anything we include in concepts/sales_tax wouldn't need an explicit bucket.

Sorry for the tangent here, I think that's a different discussion 🙂