37signals-rails

37signals の Rails ベストプラクティス

37signals（Basecamp、HEY、Fizzy）で実践されている、Ruby on Rails アプリケーション向けの包括的なコーディング原則と規約です。アーキテクチャへの影響度に基づいて優先順位付けされた、8 つのカテゴリにわたる 56 のルールが含まれています。公式の 37signals ソース（Fizzy のコードベース、STYLE.md、AGENTS.md、Rails Doctrine、DHH の「On Writing Software Well」シリーズ、非公式の 37signals スタイルガイド（Fizzy の PR 265 件））からまとめられています。

適用する場面

次のような場合に、このガイドラインを参照してください。

• 新しい Rails のコントローラー、モデル、またはビューを作成する場合
• gem と標準の Rails のどちらを使うか判断する場合
• 状態やデータベーススキーマをモデル化する場合
• バックグラウンドジョブ、キャッシュ、リアルタイム機能を設定する場合
• 37signals スタイルの規約に沿ってコードをレビューする場合
• リッチなドメインモデルに向けてリファクタリングする場合
• 認証または認可の方式を選ぶ場合
• Stimulus コントローラーや Turbo のパターンを追加する場合

優先度別のルールカテゴリ

優先度	カテゴリ	影響度	プレフィックス
1	アーキテクチャの基礎	CRITICAL	arch-
2	コントローラーと REST	CRITICAL	ctrl-
3	ドメインモデリング	HIGH	model-
4	状態管理	HIGH	state-
5	データベースとインフラストラクチャ	HIGH	db-
6	ビューとフロントエンド	MEDIUM	view-
7	コードスタイル	MEDIUM	style-
8	テスト	MEDIUM	test-

クイックリファレンス

1. アーキテクチャの基礎（CRITICAL）

• arch-rich-models - サービスオブジェクトよりリッチなドメインモデルを使う
• arch-vanilla-rails - 標準の Rails で十分です
• arch-avoid-patterns - 意図的に避けているパターンと gem
• arch-earn-abstractions - 三度目の正直の原則に従って抽象化を導入する
• arch-build-before-gems - gem に頼る前に自分で実装する
• arch-ship-to-learn - シンプルに始め、検証後にのみ複雑さを加える
• arch-domain-facades - ドメインモデルを内部の複雑さを隠すファサードとして使う
• arch-single-business-layer - ビジネスロジックを単一のレイヤーにまとめる
• arch-custom-auth - Devise よりカスタムのパスワードレス認証を使う

2. コントローラーと REST（CRITICAL）

• ctrl-crud-only - カスタムアクションより CRUD コントローラーを使う
• ctrl-model-as-resources - CRUD 以外の操作を個別のリソースとしてモデル化する
• ctrl-thin-controllers - リッチなドメインモデルと薄いコントローラーを使う
• ctrl-params-expect - パラメーターの検証に params.expect() を使う
• ctrl-controller-concerns - 横断的な処理にはコントローラーの Concern を使う
• ctrl-nested-resources - scope module を使ってリソースをネストする

3. ドメインモデリング（HIGH）

• model-concerns - 水平的なコード共有に Concern を使う
• model-normalizes - データのクリーニングに normalizes マクロを使う
• model-store-accessor - JSON カラムへのアクセスに store_accessor を使う
• model-delegated-type - ポリモーフィズムに delegated_type を使う
• model-counter-caches - N+1 の件数クエリを防ぐためにカウンターキャッシュを使う
• model-touch-chains - キャッシュ無効化に touch チェーンを使う
• model-callbacks-auxiliary - 補助的な複雑さにはコールバックを使う
• model-event-tracking - アクティビティの追跡にポリモーフィックなイベントモデルを使う
• model-poro-namespacing - PORO を親モデルの下に名前空間化する

4. 状態管理（高）

• state-records-over-booleans - Boolean カラムではなく状態をレコードとして管理
• state-timestamps - 状態遷移のタイムスタンプ
• state-enums - カテゴリ別の状態には Enum を使用
• state-db-constraints - ActiveRecord のバリデーションではなくデータベース制約を使用
• state-write-time - 読み取り時ではなく書き込み時に計算

5. データベースとインフラストラクチャ（高）

• db-backed-everything - すべてをデータベースで管理
• db-solid-queue - バックグラウンドジョブには Solid Queue を使用
• db-solid-cable - リアルタイム Pub/Sub には Solid Cable を使用
• db-solid-cache - アプリケーションのキャッシュには Solid Cache を使用
• db-multi-tenancy - Current.account を使ったパスベースのマルチテナンシー
• db-uuid-primary-keys - 主キーに UUID を使用
• db-no-foreign-keys - 外部キー制約を使用しない

6. ビューとフロントエンド（中）

• view-turbo-frames - ページの一部を切り分けるには Turbo Frames を使用
• view-turbo-streams - リアルタイム更新には Turbo Streams を使用
• view-stimulus-targets - CSS セレクターではなく Stimulus のターゲットを使用
• view-stimulus-design - Stimulus コントローラーの設計原則
• view-helpers-not-partials - ロジックはパーシャルではなくヘルパーに抽出
• view-progressive-enhancement - プログレッシブエンハンスメントを基本パターンとする
• view-fragment-caching - ビューのパフォーマンス向上にフラグメントキャッシュを使用
• view-http-caching - fresh_when と ETags を使った HTTP キャッシュ

7. コードスタイル（中）

• style-conditionals - ガード節ではなく条件分岐を展開
• style-method-ordering - 呼び出し順にメソッドを配置
• style-positive-names - メソッドとスコープには肯定形の名前を使用
• style-naming-return-values - メソッド名に戻り値を反映
• style-visibility-modifiers - 可視性修飾子の書式
• style-bang-methods - 非 bang メソッドがある場合にのみ bang メソッドを使用
• style-async-naming - 非同期操作には _later と _now の接尾辞を使用

8. テスト（中）

• test-minitest - RSpec ではなく Minitest を使用
• test-fixtures - FactoryBot ではなくデータベースフィクスチャを使用
• test-no-damage - テストによって設計を損なわない
• test-no-system-tests - システムテストではなく統合テストを使用
• test-behavior - 実装ではなく振る舞いをテスト

使用方法

詳しい説明とコード例については、各リファレンスファイルをお読みください。

• セクション定義 - カテゴリー構成と影響度
• ルールテンプレート - 新しいルールを追加するためのテンプレート

リファレンスファイル

ファイル	説明
references/_sections.md	カテゴリーの定義と順序
assets/templates/_template.md	新しいルール用のテンプレート
metadata.json	バージョンとリファレンス情報