アプリ設計の大きな流れ（2025）

アプリ設計の大きな流れ（2025）

2025年時点で推奨される Rails アプリ設計の全体像をまとめたページです。

Rails 7〜8 系の思想（Hotwire、Importmap / Vite、ViewComponent、Service層、Async Job、Security 強化 など）を踏まえた構成になっています。

---

■ 全体像（2025年版）

現代の Rails アプリ設計は、以下の 6 層を意識すると整理しやすくなります。

• UI / プレゼンテーション層（ビュー層）
• アクション層（コントローラ / Turbo Streams / FormObject）
• アプリケーション層（Service / Interactor）
• ドメイン層（PORO / Domain Models / Policies）
• 永続化層（ActiveRecord / Repository / QueryObject）
• インフラ層（外部API, Queue, Cache, CDN など）

各層の役割を明確化することで、Fat Model / Fat Controller の問題を避け、 保守性とテスト容易性が大幅に向上します。

---

1. UI / プレゼンテーション層（View, ViewComponent, Hotwire）

● 役割

• 画面描画に専念
• Ruby のロジックを極力持たない
• DOM 更新は Turbo / Stimulus に委ねる

● 主な構成要素

• ERB / Slim
• ViewComponent
• Turbo Frame
• Turbo Stream
• Stimulus

● ViewComponent の例

＜％# app/components/user_card_component.rb ％＞
class UserCardComponent ＜ ViewComponent::Base
  def initialize(user:)
    ＠user = user
  end
end

---

2. アクション層（Controller / Turbo / FormObject）

● 役割

• 入出力の橋渡し
• ロジックは Service・Domain に委譲（薄く保つ）
• Turbo Stream のレスポンス制御

● FormObject の例

class UserSignupForm
  include ActiveModel::Model

  attr_accessor :email, :password

  def save
    return false unless valid?
    User.create(email: email, password: password)
  end
end

---

3. アプリケーション層（Service / Interactor）

● 役割

• ビジネスユースケースを実行する
• Controller から呼び出される
• 複数モデルを横断する処理を担当

● Service の典型構造

class UserSignupService
  def call(form)
    User.transaction do
      user = User.create!(form.to_h)
      WelcomeMailer.send_welcome(user)
    end
  end
end

2025 年の Rails 設計では Service を使ったユースケース分離 が一般化しています。

---

4. ドメイン層（PORO / Domain Models / Policies）

● 役割

• ビジネスルールの中心
• Rails に依存しない純粋な Ruby（PORO）が中心
• 業務判定やロジックの多くをこの層に集める

● 例：年齢チェックのドメインオブジェクト

class AgeChecker
  def initialize(birthdate)
    ＠birthdate = birthdate
  end

  def adult?
    (Date.today - ＠birthdate).to_i / 365 ＞＝ 18
  end
end

---

5. 永続化層（ActiveRecord / QueryObject / Repository）

● 役割

• DB とのやり取り
• クエリの集約
• N+1 対策

● QueryObject 例

class ActiveUsersQuery
  def call
    User.where(active: true).order(created_at: :desc)
  end
end

---

6. インフラ層（外部サービス・非同期処理など）

● 役割

• メール、JOB、API 通信、SNS、決済 など
• アプリからはインターフェース越しに利用する

● 外部 API ラッパー（PORO で作成）

class PaymentApi
  def charge(user, amount)
    # 外部 API 通信の処理を書く
  end
end

---

■ 設計全体の流れ（2025年版）

以下の順で考えると、アプリが破綻しにくくなります。

• ユースケース一覧を作る（＝サービス層の入口一覧）
• ドメインルールを整理（PORO）
• データ構造（DB / モデル）を決める
• 画面（View / Turbo）を設計
• Controller で入出力を定義
• Service にユースケース処理を書く
• ドメイン層でルールを扱う
• テストを RSpec / SystemTest で書く

---

■ 2025 年の Rails 設計のキーワード

• Fat Controller / Fat Model を許容しない
• Hotwire（Turbo, Stimulus）ベースの UI
• ViewComponent でビューの再利用性を向上
• Service（Usecase）層で業務を整理
• PORO を活用したドメインロジック分離
• 非同期処理（ActiveJob / external queue）
• 外部API はインターフェース化
• テスト容易性を最優先にする

---

■ まとめ

2025 年の Rails では、 「Rails の良さを活かしつつ、責務をはっきり分離する」 ことが最重要になっています。

• UI は Hotwire と ViewComponent
• Controller は薄く
• Service がユースケースを担当
• Domain（PORO）が業務ルールの中心
• Model は永続化担当
• 外部サービスは切り出す

この流れを押さえると、大規模化しても壊れないアプリが作れます。