Great approach, thanks for share!

Nicely refined and refactored. Should be the default structure in all projects :)

Well done! At 5 minutes in, could you please tell me which episode you are referencing? Thanks

The services class was done in https://www.driftingruby.com/episodes/rails-api-app-authentication-with-json-web-tokens

hi there, Just curious, why the approach of errors and if/unless logic instead of raising an exception of the class invariants are not set? i would think it'd be much simpler to use an exception for this and keep the service logic simpler and easier to test (esp for a more complex service). I remember hearing "experts" (like Sandi Metz) say this was ok to use exceptions for business logic rule errors, and this would seem to be one). Thanks!

I think that it depends on the goals of the service object. If it were only internal interactions then this would make sense. However, if the issue was an error with an external api that you've wrapped your service object around, I would probably prefer this method.

class << self
  def call(*arg)
    new(*arg).constructor
  end
end

attr_reader :result
def constructor
  @result = call
  self
end

class << self
  def call(*arg)
    ...
  end
end

def self.call(*arg)
  ...
end