Rails wayってなんだ？？？

Posted at 2025-04-14

Rails wayってなんだ

Railsの学習をしている中で

fat_controllerは避けよう！
controllerにロジックを書くのは避けよう！
ロジックはModelに書こう！
- fat_modelは避けよう！

どっちやねん！！！！！！！と思ったときに、自分もそもそもRails wayをちゃんと理解していないなと感じたので、Rails wayについて調べてからfat_controller, fat_modelについて調べようとなったのでまずはRails wayとはなんぞやを探る記事を書く

Ruby on Railsとは

Railsガイド

Railsとは、プログラミング言語「Ruby」で書かれたWebアプリケーションフレームワークです。Railsは、あらゆる開発者がWebアプリケーション開発で必要となる作業やリソースを事前に想定することで、Webアプリケーションをより手軽に開発できるように設計されています。

Railsは、他の多くのWebアプリケーションフレームワークと比較して、アプリケーションを開発する際のコード量がより少なくて済むにもかかわらず、より多くの機能を実現できます。ベテラン開発者の多くが「RailsのおかげでWebアプリケーション開発がとても楽しくなった」と述べています。

Railsは「最善の開発方法は1つである」という、ある意味大胆な判断に基いて設計されています。何かを行うための最善の方法を1つ仮定して、それに沿った開発を全面的に支援します。言い換えれば、Railsで仮定されていない別の開発手法は行いにくくなります。

この「Rails Way」、すなわち「Railsというレールに乗って開発する」手法を学んだ人は、開発の生産性が驚くほど向上することに気付くでしょう。逆に、レールに乗らずに従来の開発手法にこだわると、開発の楽しさが減ってしまうかもしれません。

Railsの基本理念

繰り返しを避けよ（Don't Repeat Yourself: DRY）

DRYはソフトウェア開発上の原則であり、「システムを構成する知識のあらゆる部品は、常に単一であり、明確であり、信頼できる形で表現されていなければならない」というものです。同じコードを繰り返し書くことを徹底的に避けることで、コードが保守しやすくなり、容易に拡張できるようになり、バグも減らせます。

設定より規約が優先（Convention Over Configuration）

Railsでは、Webアプリケーションの機能を実現する最善の方法が明確に示されており、Webアプリケーションの各種設定についても従来の経験や慣習を元に、それらのデフォルト値を定めています。デフォルト値が決まっているおかげで、開発者の意見をすべて取り入れようとした自由過ぎるWebアプリケーションのように、開発者が大量の設定ファイルを設定せずに済みます。

Rails wayってなんなの？

Railsガイドにかかれている内容で気になった部分は以下２つ

「Rails Way」、すなわち「Railsというレールに乗って開発する」
と書かれている。

Railsは「最善の開発方法は1つである」という、ある意味大胆な判断に基いて設計されています。
設定より規約が優先

この記述から

個人の思想を柔軟に取り入れるのではなく、あくまでRailsというフレームワークが提供している方針に則って開発しましょうね。さらば与えられん。

的な感覚がある

でもまだよくわからない

Kaigi on Rails 2024の講演から探る-1

RAILS WAY, OR THE HIGHWAY

Kaigi on Rails 2024 Palkan氏による基調講演

RAILS WAYがRAILSアプリケーションを構築する哲学

生産性と幸福のための最適化
意思決定からの開放（おまかせ）
スケーラビリティを考慮した設計（スケーラビリティ：必要に応じて、必要なリソースで、必要な速さで実行すること）

RailsをWebアプリケーションとして見たときの役割はWebリクエストに答えること

デフォルトでは３つの工程（Controller->Model->View）を使ってレスポンスを生成する
しかしアプリケーションが成長するにつれてロジックを入れる箱が３つでは足りなくなる

Railsの「おまかせ」は完全ではなく埋めるべき隙間がある->認可、複雑なUI、ワークフロー、AIエージェント

この隙間を埋めようとすることでフレームワークが歪み、生産性と幸福度が下がる

あくまでRailsフレームワークは構造を与えてくれている
RAILSWAYは導きの星

迷子にならない方法

Railsを習得し、拡張すること

Railsの設計パターンを学ぶこと
規約の原則を受け入れる
Railsの構成要素をあなたのツールボックスにいれる

Railsを他のものと混ぜるのではなく拡張することが大事

担当分野の分離には新しい抽象化が必要

Railsアプリケーションに新しい抽象化レイヤーを導入する際の４つのルール

Railsらしい開発者体験とコアコンポーネントとの互換性を提供する
- カスタムアプリケーション開発者の考えではなくフレームワーク作者の考え方をもつ
抽象化レイヤーの間に明確な境界を引く
- 抽象化レイヤーを分置するためにレイヤードアーキテクチャの原則を参照できる
- 各抽象化は特定のアーキテクチャレイヤーに属する必要がある
- データ原則として上から下に流れて、そこで各抽象化は自分より下位の者だけ知ることができる
- それぞれの装花rあどこまで下位層にアクセスできるかを制限することも可能なので疎結合が実現
  - Presentation
    - Controller
    - Channels
    - Views
  - Application
    - Jobs
    - Mailers
  - Domain
    - Models
  - Infrastructure
    - Adapters(DB, Mail)
    - API clients
介入より抽象：コード内で既存の抽象化を見つけよう
関心事と複雑さのレベルを分離する

フレームワークと戦わなければRails wayで成長できることは可能

Railsに似た新しい抽象化を導入する
明確な境界を引く
担当分野と複雑性を分離する
アプリケーションに属する

Kaigi on Rails 2024の講演から探る-2

Railsの仕組みを理解してモデルを上手に育てる - モデルを見つける、モデルを分割する良いタイミング

Railsの仕組みを理解してモデルを上手に育てる

Kaigi on Rails 2024 igaiga氏による講演

Rails wayに関わっていそうな部分を抜粋

行為を記録するモデル -> イベント型モデル

Order（注文）
Shipment（出荷）
Payment（支払い）

名詞であるモデルに「~する」とつけると行為になるもの

どんなメリットがあるか

適切なイベント型モデルを探し出せると、責務がてきせうなモデルに処理かける

複数モデルにまたがる処理を書きたい問題を解決できる

つくられたのはモデルでRails wayに乗った設計方法になっている

Rails wayに乗っていると迷いづらく説明も簡単になる
できるだけ遠くまでRails wayに乗っていきたい

Service層を入れるのはできるだけやめてほしい

Railsの特徴

Railsはレイヤー分割を減らして記述するコード量を減らす設計
レイヤーとはルーティング、コントローラー、ビュー、モデルなど
モデルが担当する仕事
- ORマッパー
- バリデーション
- コールバック
- フォームオブジェクト
- ビジネスロジック置き場
- いろいろな機能を併せ持った密結合な設計 -> Rails