Introducing Mutations: Putting SOA on Rails for security and maintainability

  class UserService
  service :signup do |config|
    config.required do end
    config.optional do end
    config.execute
        # signup stuff here
    end
  end
   
  service :delete_account do |config|
    config.required do end
    config.optional do end
    config.execute
        # signup stuff here
    end
  end
  end

But I guess the controllers are created for this. DHH says controllers are responsible for mailing and stuff, which is more correct than in the models with callbacks.

What I think you're getting at is: can you just replace controllers with mutations? That's an interesting concept that I've thought a bit about. In practice, we have found controllers to still be useful in collecting some information and doing 'wiring'. They're also nice because your SOA shouldn't really be concerned with the presentation of the response.

Finally, where do you put your mailings? You're right that controllers > models, but I'd also say that mutations > controllers > models.

Often these patterns are treated and discussed as an either/or decision, which I don't agree with. There are many places in an app where the default and simple Rails way is the right choice. However as apps get more complex, there is also a need for approaches like the one presented here.

My rule for choosing the right approach is this:

If it's just a simple CRUD controller where it receives input from a simple form and writes attributes to a single model, with no AR callbacks involved, then omakase is perfectly acceptable. In that case I don't want to have to jump through all kinds of hoops and overcome unnecessary friction added by enterprisey patterns.

However, as soon as I have to use AR callbacks, add more lines to my controller action, or touch more than one model, that's a clear indication that a service object makes sense.

Mutations looks like a great solution for the latter case. It brings in some DCI goodness as well. The key is that some operations require complex context (object graphs, permissions, dependent operations), and that context should be treated as a first class citizen.