Service Objects у Rails 2026: Патерни Проєктування, PORO та Питання на Технічну Співбесіду

Service objects у Rails дозволяють винести бізнес-логіку з контролерів та моделей у окремі класи Plain Old Ruby Objects (PORO). Цей патерн підтримує застосунки Rails у стані, зручному для супроводу, по мірі їх зростання, а інтерв'юери часто перевіряють його знання для оцінки розуміння кандидатом чистої архітектури.

Чому Service Objects Вирішують Проблему Fat Model та Fat Controller

Rails заохочує розміщення логіки десь. Без керівництва команди запихають її в моделі ("fat models, skinny controllers"), поки класи ActiveRecord не розростаються до тисяч рядків. Інші залишають її в контролерах, роблячи екшени неможливими для ізольованого тестування.

Service objects пропонують третій шлях: доменна логіка живе у виділених класах, які не залежать від нічого з Rails, окрім того, що явно вимагають. Це розділення робить код тестованим без завантаження повного фреймворка, переносним між різними точками входу (контролери, фонові задачі, консоль) та читабельним, оскільки кожен клас робить одну річ.

Rails Guides не приписують service objects, але спільнота стандартизувалась навколо цього патерну. Акцент Rails 8 на простоті, з Solid Queue та Solid Cache, що замінюють зовнішні залежності, робить PORO ще привабливішими: менше гемів, більше чистого Ruby.

Анатомія Продакшн-Готового Service Object

Service object потребує трьох речей: конструктора, що приймає залежності, єдиного публічного методу call та типу повернення, що сигналізує про успіх або невдачу.

# 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

Конструктор приймає user_repo та mailer зі значеннями за замовчуванням. Продакшн код використовує значення за замовчуванням; тести ін'єктують моки. Метод call валідує, зберігає, надсилає email і обгортає кожен результат в об'єкт Result.

Побудова Мінімального Класу Result Без Гемів

Деякі команди одразу звертаються до dry-monads. Гем надійний, але додає криву навчання. 30-рядковий клас Result покриває більшість потреб:

# 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

Цей Result підтримує ланцюжок з on_success та on_failure, надає структуровані коди помилок і не вимагає жодних залежностей. Контролери споживають його чисто:

# 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

Конвенції Найменування, що Сигналізують про Намір

Дві конвенції домінують:

Стиль з дієслівною фразою читається природно: Users::CreateAccount.new.call(params). Суфікс -or працює, але додає склади без збільшення ясності.

Структура каталогів також має значення. Групування за доменом тримає пов'язані service objects разом:

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 для Тестованих Service Objects

Жорстко закодовані залежності роблять тестування болісним. Цей service object не можна протестувати без звернення до бази даних та надсилання реальних emails:

# Уникайте: жорстко закодовані залежності
class CreateAccount
  def call(params)
    user = User.create!(params)        # Пряме звернення до моделі
    UserMailer.welcome(user).deliver   # Пряме звернення до mailer
  end
end

Ін'єкція через конструктор вирішує це:

# Краще: ін'єктовані залежності
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

Тести тепер підставляють фейкові об'єкти:

# 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

Без бази даних, без emails, швидке виконання. Документація RSpec охоплює class_double та instance_double для моків з верифікацією типів.

Питання на Співбесіді про Rails Service Objects

Ці питання з'являються на співбесідах для mid-level та senior Rails розробників. Слід підготувати конкретні відповіді з прикладами коду.

П: Коли бізнес-логіка повинна бути в моделі, а коли в service object?

Моделі володіють валідаціями, асоціаціями, скоупами та поведінкою для одного запису. Service objects обробляють операції, що охоплюють кілька моделей, вимагають зовнішніх викликів або потребують явних меж транзакцій. Модель User валідує формат email; сервіс CreateAccount створює користувача, надсилає вітальний email та налаштовує параметри за замовчуванням.

П: Як обробляти помилки в service objects без винятків?

Слід повертати об'єкт Result зі станами успіх/невдача. Це робить обробку помилок явною на стороні того, хто викликає, уникає потоку керування на основі винятків і надає структуровані коди помилок для різних режимів збою. Винятки залишаються доречними для справді виняткових умов (збій бази даних, помилка мережі), а не порушень бізнес-правил.

П: Яка різниця між service object та інтерактором?

Інтерактори (з гемів на кшталт interactor) — це service objects з визначеним інтерфейсом: вони отримують хеш context, мутують його та сигналізують про невдачу через context.fail!. Service objects як PORO не мають наперед визначеного інтерфейсу, даючи командам більше гнучкості, але менше послідовності.

П: Як тестувати service object, який викликає зовнішнє API?

Слід ін'єктувати HTTP-клієнт як залежність. У тестах передається стаб, що повертає підготовлені відповіді. Інструменти на кшталт WebMock або VCR можуть записувати та відтворювати HTTP-взаємодії, але ін'єкція через конструктор повністю уникає мережевих викликів у юніт-тестах.

Більше підготовки до співбесід Rails можна знайти у посібнику з питань співбесід Rails, що охоплює RSpec та патерни тестування.

Railway-Oriented Design для Складних Потоків

Railway-oriented програмування розглядає потік як дві паралельні колії: успіх продовжує вперед, невдача негайно виходить. Кожен крок або просувається по колії успіху, або перемикається на колію невдачі.

# 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

Клас Result потребує методу then, який продовжує лише при успіху:

# Додати до app/services/result.rb
def then
  return self if failure?
  yield(value)
end

Якщо резервування на складі зазнає невдачі, оплата ніколи не запуститься. Якщо оплата зазнає невдачі, доставка ніколи не запуститься. Кожен крок повертає Result, і ланцюжок переривається при першій невдачі.

Коли Service Objects Стають Антипатерном

Service objects вирішують реальні проблеми, але можуть непотрібно розмножуватись. Слід звертати увагу на ці попереджувальні знаки:

• Однорядкові service objects: Якщо service лише викликає один метод моделі, він додає непрямість без цінності. User.authenticate(email, password) краще за AuthenticateUser.new.call(email, password), коли логіка проста.

• Service objects, що існують лише для тестування: Ін'єкція залежностей полегшує тестування, але створення service objects виключно для обгортання методів моделі заради тестованості свідчить, що реальна проблема — це налаштування тестів, а не архітектура.

• Анемічні service objects без логіки: Service objects, які лише делегують моделям без додавання поведінки — це церемонія. Інженерний блог Netguru обговорює цю проблему надмірної екстракції.

Альтернатива: використання PORO вибірково поряд з Concerns для спільної поведінки моделей, Value Objects для доменних концепцій на кшталт Money чи DateRange, та методів моделей для операцій з одним записом.

Ключові Висновки для Проєктування Rails Service Objects

• Екстракція до service object, коли логіка охоплює кілька моделей, вимагає зовнішніх викликів або потребує явної обробки помилок
• Використання єдиного публічного методу call, що повертає об'єкт Result, а не сирі значення або винятки
• Ін'єкція залежностей через конструктор з розумними значеннями за замовчуванням для продакшн використання
• Найменування service objects дієслівними фразами на кшталт CreateAccount або PlaceOrder, що описують дію
• Організація service objects за доменом (users/, orders/) замість плоскої структури каталогів
• Початок з мінімального класу Result перед додаванням гемів на кшталт dry-monads
• Резервування винятків для збоїв інфраструктури, а не порушень бізнес-правил
• Уникання створення service objects для однорядкових операцій, які моделі обробляють природно