Started trying out @kaspth's Associated Object gem, and I'm really digging it as a way to organize model logic. I'm only scratching the surface of using it so far, but it's delivering as advertised. https://github.com/kaspth/active_record-associated_object
Was having so much fun, I started a rough generator to make it a little faster, and Kasper already polished it up and created a PR. https://github.com/kaspth/active_record-associated_object/pull/23
@garrettdimon @kaspth @jamie From the README:
"But sometimes app/services can turn into another junk drawer that doesn't help you build and make concepts for your Domain Model."
"sometimes"?????! 😂
Interesting idea.
Also I like that they're focused around a particular model. As a concept, it could help serve as a reminder to prevent Service object that all too easily become some of the worst examples of the Mediator pattern that I've ever seen (or written because I suck too).
And, I suppose, there are legitimate cases (see: complicated business processes) where you may legitimately just need a Whole Bunch O' Different Model Objects™️ to achieve an objective. But I've seen this become the bulk of app business logic way too often over the past 10 years.
@elight @garrettdimon @jamie yeah, I just find things become more focused when they're grounded inside another model's namespace and it helps discoverability too.
And then the cases where you're using multiple models, like you mention, you can still do those as a service object if you want to — and that process could use Associated Objects internally too.
@kaspth @elight @jamie The code has to go _somewhere_, and based on the tactics I have experience with, this one feels like a very reasonable set of tradeoffs.
Only using it in one spot, but the code all reads and feels so much better. Having done something similar with PORO’s, this feels cleaner and more intentional.
Paul H
Garrett Dimon 
Evan Light
Kasper Timm Hansen