service-objects-vs-fat-models

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.