Rails Service Objects nel 2026: Design Pattern, PORO e Domande per Colloqui Tecnici

I Service Objects in Rails estraggono la logica di business da controller e model in Plain Old Ruby Objects (PORO). Questo pattern mantiene le applicazioni Rails manutenibili mentre crescono, e gli intervistatori lo testano frequentemente per valutare la comprensione di un candidato della clean architecture.

Perché i Service Objects risolvono i problemi di Fat Model e Fat Controller

Rails incoraggia a mettere la logica da qualche parte. Senza guida, i team la spingono nei model ("fat model, skinny controller") finché le classi ActiveRecord non crescono a migliaia di righe. Altri la lasciano nei controller, rendendo impossibile testare le action in isolamento.

I Service Objects offrono una terza via: la logica di dominio vive in classi dedicate che non dipendono da nulla di Rails tranne ciò che richiedono esplicitamente. Questo disaccoppiamento rende il codice testabile senza caricare l'intero framework, portabile attraverso diversi punti di ingresso (controller, background job, console) e leggibile perché ogni classe fa una cosa sola.

Le Rails Guides non prescrivono i Service Objects, ma la community si è standardizzata su questo pattern. Rails 8 enfatizza la semplicità con Solid Queue e Solid Cache che sostituiscono le dipendenze esterne, rendendo i PORO ancora più attraenti: meno gem, più Ruby puro.

Anatomia di un Service Object production-ready

Un Service Object necessita di tre cose: un costruttore che riceve le dipendenze, un singolo metodo pubblico call e un tipo di ritorno che segnala successo o fallimento.

# app/services/users/create_account.rb
module Users
  class CreateAccount
    def initialize(user_repo: User, mailer: UserMailer)
      @user_repo = user_repo
      @mailer = mailer
    end

    def call(params)
      user = @user_repo.new(params)
      return Result.failure(:validation_failed, user.errors) unless user.valid?

      user.save!
      @mailer.welcome_email(user).deliver_later
      Result.success(user)
    rescue ActiveRecord::RecordNotUnique
      Result.failure(:email_taken, "Email already registered")
    end
  end
end

Il costruttore accetta user_repo e mailer con valori predefiniti. Il codice di produzione usa i default; i test iniettano mock. Il metodo call valida, persiste, invia un'email e avvolge ogni risultato in un oggetto Result.

Costruire una classe Result minimale senza gem

Alcuni team raggiungono subito dry-monads. La gem è solida, ma aggiunge una curva di apprendimento. Una classe Result di 30 righe copre la maggior parte delle necessità:

# app/services/result.rb
class Result
  attr_reader :value, :error, :code

  def initialize(success:, value: nil, error: nil, code: nil)
    @success = success
    @value = value
    @error = error
    @code = code
  end

  def success? = @success
  def failure? = !@success

  def self.success(value) = new(success: true, value: value)
  def self.failure(code, error = nil) = new(success: false, code: code, error: error)

  def on_success
    yield(value) if success?
    self
  end

  def on_failure
    yield(code, error) if failure?
    self
  end
end

Questa classe Result supporta il concatenamento con on_success e on_failure, espone codici di errore strutturati e non richiede dipendenze. I controller la consumano in modo pulito:

# app/controllers/users_controller.rb
class UsersController < ApplicationController
  def create
    result = Users::CreateAccount.new.call(user_params)

    result
      .on_success { |user| redirect_to user, notice: "Account created" }
      .on_failure { |code, error| render :new, status: :unprocessable_entity }
  end

  private

  def user_params
    params.require(:user).permit(:email, :password, :name)
  end
end

Convenzioni di naming che segnalano l'intento

Due convenzioni dominano:

Lo stile della frase verbale si legge naturalmente: Users::CreateAccount.new.call(params). Il suffisso -or funziona ma aggiunge sillabe senza chiarezza.

Anche la struttura delle directory è importante. Raggruppare per dominio mantiene insieme i service correlati:

app/services/
  users/
    create_account.rb
    reset_password.rb
    update_profile.rb
  orders/
    place_order.rb
    cancel_order.rb
    calculate_totals.rb
  result.rb

Dependency Injection per service testabili

Le dipendenze hardcoded rendono il testing doloroso. Questo service non può essere testato senza colpire il database e inviare email reali:

# Da evitare: dipendenze hardcoded
class CreateAccount
  def call(params)
    user = User.create!(params)        # Chiamata diretta al model
    UserMailer.welcome(user).deliver   # Chiamata diretta al mailer
  end
end

L'iniezione attraverso il costruttore risolve questo:

# Meglio: dipendenze iniettabili
class CreateAccount
  def initialize(user_repo: User, mailer: UserMailer)
    @user_repo = user_repo
    @mailer = mailer
  end

  def call(params)
    user = @user_repo.create!(params)
    @mailer.welcome(user).deliver_later
    Result.success(user)
  end
end

I test ora sostituiscono fake:

# spec/services/users/create_account_spec.rb
RSpec.describe Users::CreateAccount do
  let(:fake_repo) { class_double(User) }
  let(:fake_mailer) { class_double(UserMailer) }
  let(:service) { described_class.new(user_repo: fake_repo, mailer: fake_mailer) }

  it "returns success with valid params" do
    user = instance_double(User, valid?: true)
    allow(fake_repo).to receive(:new).and_return(user)
    allow(user).to receive(:save!)
    allow(fake_mailer).to receive_message_chain(:welcome_email, :deliver_later)

    result = service.call(email: "test@example.com", password: "secure123")

    expect(result).to be_success
  end
end

Nessun database, nessuna email, esecuzione rapida. La documentazione RSpec copre class_double e instance_double per mock verificati per tipo.

Domande da colloquio sui Rails Service Objects

Queste domande appaiono nei colloqui Rails di livello mid e senior. Preparare risposte concrete con esempi di codice.

D: Quando la logica di business dovrebbe vivere in un model rispetto a un Service Object?

I model possiedono validazioni, associazioni, scope e comportamento single-record. I Service Objects gestiscono operazioni che attraversano più model, richiedono chiamate esterne o necessitano di confini di transazione espliciti. Un model User valida il formato dell'email; un service CreateAccount crea l'utente, invia un'email di benvenuto e provvede alle impostazioni predefinite.

D: Come si gestiscono gli errori nei Service Objects senza eccezioni?

Restituire un oggetto Result con stati success/failure. Questo rende la gestione degli errori esplicita nel chiamante, evita il flusso di controllo basato su eccezioni e fornisce codici di errore strutturati per diverse modalità di fallimento. Le eccezioni rimangono appropriate per condizioni veramente eccezionali (database down, errore di rete) piuttosto che per violazioni delle regole di business.

D: Qual è la differenza tra un Service Object e un Interactor?

Gli Interactor (da gem come interactor) sono Service Objects con un'interfaccia specifica: ricevono un hash context, lo mutano e segnalano il fallimento attraverso context.fail!. I Service Objects come PORO non hanno un'interfaccia prescritta, dando ai team più flessibilità ma meno consistenza.

D: Come si testa un Service Object che chiama API esterne?

Iniettare il client HTTP come dipendenza. Nei test, passare uno stub che restituisce risposte predefinite. Tool come WebMock o VCR possono registrare e riprodurre interazioni HTTP, ma l'iniezione tramite costruttore evita completamente le chiamate di rete negli unit test.

Per ulteriore preparazione ai colloqui Rails, consultare la guida alle domande da colloquio Rails che copre RSpec e pattern di testing.

Railway-Oriented Design per workflow complessi

La programmazione railway-oriented tratta un workflow come due binari paralleli: il successo continua in avanti, il fallimento esce immediatamente. Ogni step o avanza sul binario del successo o passa al binario del fallimento.

# app/services/orders/place_order.rb
module Orders
  class PlaceOrder
    def initialize(
      inventory: InventoryService.new,
      payment: PaymentService.new,
      fulfillment: FulfillmentService.new
    )
      @inventory = inventory
      @payment = payment
      @fulfillment = fulfillment
    end

    def call(cart:, payment_method:)
      validate_cart(cart)
        .then { |items| reserve_inventory(items) }
        .then { |reservation| charge_payment(reservation, payment_method) }
        .then { |charge| create_fulfillment(charge) }
    end

    private

    def validate_cart(cart)
      return Result.failure(:empty_cart, "Cart is empty") if cart.items.empty?
      Result.success(cart.items)
    end

    def reserve_inventory(items)
      @inventory.reserve(items)
    end

    def charge_payment(reservation, payment_method)
      result = @payment.charge(reservation.total, payment_method)
      return result if result.failure?

      Result.success({ reservation: reservation, charge: result.value })
    end

    def create_fulfillment(data)
      @fulfillment.create(data[:reservation], data[:charge])
    end
  end
end

La classe Result necessita di un metodo then che procede solo in caso di successo:

# Aggiungere a app/services/result.rb
def then
  return self if failure?
  yield(value)
end

Se la prenotazione dell'inventario fallisce, il pagamento non viene mai eseguito. Se il pagamento fallisce, il fulfillment non viene mai eseguito. Ogni step restituisce un Result, e la catena si interrompe al primo fallimento.

Quando i Service Objects diventano un anti-pattern

I Service Objects risolvono problemi reali ma possono proliferare inutilmente. Attenzione a questi segnali d'allarme:

• Service di una riga: Se il service chiama solo un metodo del model, il service aggiunge indirezione senza valore. User.authenticate(email, password) è meglio di AuthenticateUser.new.call(email, password) quando la logica è semplice.

• Service che esistono solo per il testing: Iniettare dipendenze rende il testing più facile, ma creare service solo per wrappare metodi del model per la testabilità suggerisce che il vero problema è il setup del test, non l'architettura.

• Service anemici senza logica: Service che delegano solo ai model senza aggiungere comportamento sono cerimonia. Il Netguru engineering blog discute questo problema di over-extraction.

L'alternativa: usare i PORO selettivamente insieme ai Concern per comportamento condiviso del model, Value Object per concetti di dominio come Money o DateRange, e metodi del model per operazioni single-record.

Punti chiave per il design dei Rails Service Object

• Estrarre in un Service Object quando la logica attraversa più model, richiede chiamate esterne o necessita di gestione esplicita degli errori
• Usare un singolo metodo pubblico call che restituisce un oggetto Result, non valori grezzi o eccezioni
• Iniettare dipendenze attraverso il costruttore con default sensati per l'uso in produzione
• Nominare i service con frasi verbali come CreateAccount o PlaceOrder che descrivono l'azione
• Organizzare i service per dominio (users/, orders/) piuttosto che in una struttura di directory piatta
• Iniziare con una classe Result minimale prima di aggiungere gem come dry-monads
• Riservare le eccezioni per fallimenti infrastrutturali, non per violazioni delle regole di business
• Evitare di creare service per operazioni di una riga che i model gestiscono naturalmente