rails-backend

Rails Backend Skill

Opinionated conventions for Rails backend code. Architecture is built on a single principle: place the domain model at the center. Controllers, jobs, and the console are all boundaries that orchestrate domain logic — they contain no business logic themselves.

Sub-files:

• MODELS.md — Concern architecture, associations, scoping, callbacks
• CONTROLLERS.md — REST conventions, strong params, concerns
• JOBS.md — _now/_later pattern, multi-tenancy context
• API.md — JSON responses, serialization, versioning

---

Core Philosophy

Domain Model at the Center

Controller ──┐
             ▼
Console ──► Domain Model ◄── Job
             ▲
Script  ─────┘

card.close works identically whether called from a controller, job, console, or test. The domain model is the single source of truth for business behavior.

No New Architectural Artifacts

No service objects, form objects, interactors, or command pattern libraries. Building blocks:

• Models — domain entities and operations (ActiveRecord and plain Ruby)
• Concerns — organize model behavior into cohesive modules
• Controllers — HTTP boundary only
• Jobs — async boundary; delegate to model methods
• Views — render domain state (templates, not view components)

When something doesn't fit in an entity, create a plain Ruby object with a semantic name — not a new architectural pattern. A Signup class, not a SignupService. A Notifier, not a NotificationInteractor.

Preference for Rails Defaults

Minitest over RSpec · view templates over view components · ActiveRecord callbacks over observer patterns · Current over dependency injection · concerns over decorator libraries.

---

Domain Model Overview

Account (tenant/organization)
  └── Users (members with roles)
  └── Boards (project spaces)
       └── Columns (workflow stages)
       └── Cards (tasks/issues)
            └── Comments, Assignments, Tags