dhh-rails-style

RESTful Rails architecture uses thin controllers that route to seven standard actions (index, show, new, create, edit, update, destroy) and fat models that contain business logic, validations, and concerns. This separation keeps controllers lightweight and models responsible for domain logic.

DHH Rails style enforces conventional patterns from 37signals: RESTful CRUD mappings, fat models with concerns, Current attributes for multi-tenant context, Turbo for dynamic interactions, and minimal external dependencies. Use this approach for Rails applications prioritizing simplicity and framework conventions over custom abstractions.

Multi-tenant Rails routing uses path-scoped resources with Current attributes to maintain tenant context across requests without explicit parameters. Current provides thread-safe storage for request-scoped data like account or user context, eliminating dependency injection boilerplate.

Yes. Turbo drives and morphs HTML without JavaScript frameworks, while Stimulus provides lightweight interactivity. Both integrate directly with Rails conventions and avoid heavy client-side dependencies, aligning with DHH's minimal-coupling philosophy.

Avoid excessive service objects, Redis for core features, GraphQL without clear need, and heavy external dependencies. DHH style favors database-backed design, Rails concerns for shared logic, and REST APIs over custom abstraction layers that obscure conventional Rails behavior.

Review for RESTful action alignment, business logic placement in models, overuse of service objects, and unnecessary dependencies. Refactoring should consolidate thin controllers, push logic to models and concerns, and simplify architecture toward Rails conventions rather than custom patterns.