Three locations are commonly used for business logic that responds to user input beyond the common "pass the params hash to ActiveRecord#create " Rails behavior. Here are our options:
Put the extra logic in the controller. This is the Rails core team's preferred method, and if there isn't much logic it works perfectly fine. In my experience this location doesn't work as well for complex logic. It's challenging to test, awkward to refactor, and difficult to share if that becomes an issue. It also becomes confusing if there is more than one complicated action in the controller.
Put the extra logic in a class method of the associated model. This was my go-to move for years. It's somewhat easier to test, but still kind of awkward to refactor—Ruby class method semantics are a pain. It also makes the model more complicated.
Create a class to encapsulate the logic and workflow. This tends to be my first choice these days. It's the easiest to test and the best able to manage complexity changes as they come. The main downside is you wind up with a lot of little classes, but I don't mind having a lot of little pieces anyway.
"The key point for an "interactor" extraction is imo when you have multiple models being created in symphony, like a Signup model."