The Rails Directory Structure

Direct Answer

A Rails application's directories separate code by responsibility. Most application code lives under app/; routes and environment settings live under config/; migrations and schema information live under db/; tests live under test/ or a project-selected spec/; reusable tasks often live under lib/; and generated runtime files use folders such as log/, storage/, and tmp/. The structure supports Rails naming and autoloading conventions, so files should be placed by what they do rather than by convenience.

Deep Dive & Architecture

The top-level tree separates files by how they change. Application behaviour evolves in app; deployment and environment choices live in config; database evolution is recorded in db/migrate; dependency versions are locked through the Gemfile files; and automated checks evolve alongside behaviour in the test tree.

Within app, paths normally mirror constant namespaces. app/jobs/billing/reconcile_job.rb is expected to define Billing::ReconcileJob. Views are grouped by controller or component rather than becoming Ruby constants, but their placement still drives conventional lookup.

Migrations are history, while db/schema.rb or db/structure.sql describes the current database shape for setup and inspection. Editing an old migration that has already run in shared environments can make installations disagree; a new migration records the next change.

Runtime directories should not become hidden source locations. Logs, cached files, process IDs, uploaded development files, and temporary artifacts can be replaced between environments. Code required to understand the application belongs in versioned source or explicit configuration instead.

Code Example

# app/models/product.rb
class Product < ApplicationRecord
end

# app/controllers/products_controller.rb
class ProductsController < ApplicationController
  def show
    @product = Product.find(params[:id])
  end
end

# app/views/products/show.html.erb
# <h1><%= @product.name %></h1>

# test/controllers/products_controller_test.rb
# verifies the HTTP behaviour of ProductsController

Common Mistakes & Pitfalls

Not knowing where a feature lives (model in app/models, not app/controllers), or putting logic outside the conventional folders.