service-objects-vs-fat-models

Define criteria for extracting service objects in Ruby on Rails applications.

21|2|Updated May 24, 2026
One-click install
npx skills add https://github.com/sandeepmvl/rails-skills --skill service-objects-vs-fat-models
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: service-objects-vs-fat-models
Source: https://github.com/sandeepmvl/rails-skills/tree/main/skills/03-service-objects-vs-fat-models
Command: npx skills add https://github.com/sandeepmvl/rails-skills --skill service-objects-vs-fat-models

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

AI coding agents consistently over-extract service objects for every Rails controller action, adding unnecessary indirection and violating senior Rails developer conventions. This skill encodes the "earn it" criteria for extracting service objects, ensuring business logic is only moved out of models when it provides clear value, reducing technical debt and improving code maintainability.

Core Features & Use Cases

  • Extraction trigger criteria: Learn the 4 specific conditions that justify extracting a service object, including multi-model transactional orchestration, external API integrations, and workflows with multiple distinct outcomes.
  • Implementation best practices: Covers Result pattern implementation using Ruby's built-in Data.define, service object naming conventions (VerbNoun style, no redundant suffixes), and proper separation between services, background jobs, and form objects.
  • Anti-pattern prevention: Identifies and avoids common mistakes like god services, wrapping single model methods in services, synchronous external calls in request paths, and premature use of dry-monads.
  • Real-world use case: Refactor a multi-step checkout workflow spanning Cart, Order, LineItem, and Stripe into a well-structured service object with proper error handling, instead of scattering logic across multiple models.

Quick Start

Consult this skill whenever you need to decide if a Rails business logic workflow belongs in a model, service object, or background job, or when asked about service object naming conventions and common anti-patterns to avoid.

Frequently Asked Questions about service-objects-vs-fat-models

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
When should I extract service objects in Rails instead of using fat models?

Extract service objects in Rails only when logic involves multi-model transactional orchestration, external API integrations, or workflows with multiple distinct outcomes to avoid unnecessary indirection.

How do I implement the Result pattern in Ruby on Rails service objects?

Implement the Result pattern in Ruby on Rails service objects using Ruby's built-in Data.define to handle multiple distinct workflow outcomes cleanly without adding unnecessary dependencies.

What are common Rails service object anti-patterns to avoid?

Common Rails service object anti-patterns include creating god services, wrapping single model methods in services, making synchronous external API calls in request paths, and premature use of dry-monads.

Should I use a service object or a background job for external API calls in Rails?

Use background jobs for external API calls in Rails rather than service objects to prevent blocking the request path, keeping service objects focused on synchronous multi-model transactional orchestration.

What is the correct naming convention for Rails service objects?

The correct naming convention for Rails service objects uses a VerbNoun style without redundant suffixes, ensuring clear intent and aligning with senior Ruby on Rails developer conventions.

How do I refactor a multi-step checkout workflow in Rails without creating a fat model?

Refactor a multi-step Rails checkout workflow spanning Cart, Order, and Stripe by extracting a single service object to handle transactional orchestration and error handling instead of scattering logic across models.