Ruby’s flexibility is great until every developer on the team writes service objects differently. After years of working with Rails codebases where each service had its own structure, error handling, and testing conventions, I built Servactory — a framework that standardizes service objects through a typed, declarative DSL.

The core idea is three separate attribute layers: inputs (what comes in), internals (working state), and outputs (what goes out). Each is a distinct declaration with its own namespace and type checking. Combined with declarative make calls that define action order, the data flow through a service is visible at a glance:

class Payments::Process < ApplicationService::Base
  input :payment, type: Payment

  internal :charge_result, type: Servactory::Result

  output :payment, type: Payment

  make :validate_status!
  make :perform_request!
  make :handle_response!
  make :assign_payment

  private

  def validate_status!
    return if inputs.payment.pending?

    fail!(
      message: "Payment has already been processed",
      meta: { status: inputs.payment.status }
    )
  end

  def perform_request!
    internals.charge_result = Gateway::Charge.call(
      amount: inputs.payment.amount,
      token: inputs.payment.token
    )
  end

  def handle_response!
    internals.charge_result
             .on_success { handle_success! }
             .on_failure { handle_failure! }
  end

  def handle_success!
    inputs.payment.complete!(internals.charge_result.response.id)
  end

  def handle_failure!
    inputs.payment.fail!(internals.charge_result.error.message)
    fail_result!(internals.charge_result)
  end

  def assign_payment
    outputs.payment = inputs.payment
  end
end

What I think makes it worth trying:

• Type safety on all three layers — inputs, internals, and outputs are each type-checked independently
• Explicit data flow — the separation into three namespaces (inputs.*, internals.*, outputs.*) eliminates “where does this value come from?” confusion
• Structured failure handling — fail! with metadata, typed failures, fail_result! for error propagation, on_success/on_failure hooks on the result
• Action grouping — stage blocks with wrap_in for transactions, only_if conditions, and rollback handlers
• Full ecosystem — custom RuboCop cops, OpenTelemetry instrumentation, RSpec matchers, Rails generators

Supports Ruby 3.2+ and Rails 5.1 through 8.1. 110K+ gem downloads, 138 releases, MIT licensed. I’ve been using it in production for over two years.

Would love to hear feedback, especially from people who’ve tried other approaches (Interactor, ActiveInteraction, Trailblazer, or plain POROs).

Docs: https://servactory.com