Master Architectural Patterns in Ruby on Rails (MVC, DDD, More)

🧠 Detailed Explanation

MVC stands for Model-View-Controller. It is a way to organize your Rails app in 3 clear parts:

• Model: Think of this as the part that talks to the database. It holds the data and business logic. Example: Article, User.
• View: This is what the user sees. It’s the HTML, CSS, and embedded Ruby (ERB) code that shows the page in the browser.
• Controller: This is the middleman. It takes user input (like clicking a link), asks the Model for data, and passes it to the View.

Let’s imagine a **real-world example**:

• You visit /articles in your browser.
• The Controller (ArticlesController) gets this request.
• It asks the Model (Article) to get all articles from the database.
• Then it sends that data to the View (index.html.erb).
• The View shows all the articles on your screen.

Think of it like a restaurant:

• Model = Kitchen (where food is prepared)
• Controller = Waiter (takes your order and brings your food)
• View = Plate/Table (how food is served and what you see)

This way of organizing code helps developers keep everything clean, easy to manage, and work in teams without confusion.

📘 Key MVC Terms & Best Practices in Rails

🌐 MVC Flow Cycle (Step-by-Step)

Here’s how a request flows through a typical Rails application using the MVC pattern:

1. 🔗 User Action: A user visits a URL in the browser (e.g., /articles).
2. 🌐 Router (config/routes.rb): Rails checks this file to find out which controller and action should handle the request.
3. 🧭 Controller: The matched controller action is called (e.g., ArticlesController#index). This acts as the traffic manager.
4. 🧠 Model: If needed, the controller asks the model to fetch or save data from the database using ActiveRecord (e.g., Article.all).
5. 👀 View: The controller sends that data to the view template (e.g., index.html.erb), which generates HTML to show in the browser.
6. 📲 Response: Rails sends the final HTML back to the user’s browser. The user sees the result.

Summary Flow:

User → Router → Controller → Model → Controller → View → Response

Example: Visiting /articles in the browser

• routes.rb: maps to articles#index
• ArticlesController: loads @articles = Article.all
• index.html.erb: loops through @articles and displays them
• Browser: shows the page with all articles

Think of it like a restaurant:

• You (User): place an order (URL request)
• Waiter (Controller): takes your order
• Kitchen (Model): prepares your food (data)
• Plate (View): presents the food
• Back to You (Browser): you eat it (see the result)

💡 Examples

# app/models/article.rb
  class Article < ApplicationRecord
    validates :title, presence: true
  end
  
  # app/controllers/articles_controller.rb
  class ArticlesController < ApplicationController
    def index
      @articles = Article.all
    end
  end
  
  # app/views/articles/index.html.erb
  <% @articles.each do |article| %>
    <h2><%= article.title %></h2>
  <% end %>
        

🔁 Alternative Concepts

• MVVM (Model-View-ViewModel)
• HMVC (Hierarchical MVC)
• Component-based architecture (used in React)

🛠️ Technical Questions & Answers

Q1: How do you define a model in Rails?

A: Use a class that inherits from ApplicationRecord. It represents a database table.

class Article < ApplicationRecord
        validates :title, presence: true
      end

Q2: What is a controller in Rails?

A: A controller receives requests from the browser and decides what to do — like fetching data and rendering a view.

class ArticlesController < ApplicationController
        def index
          @articles = Article.all
        end
      end

Q3: How do you create a route in Rails?

A: You define routes in config/routes.rb file.

get '/articles', to: 'articles#index'

Q4: How does Rails connect controller to views?

A: If a controller action is called, Rails automatically renders a view with the same name.

# Controller
      def show
        @article = Article.find(params[:id])
      end
      
      # View: app/views/articles/show.html.erb

Q5: What is the naming convention in MVC?

A: Models are singular (Article), Controllers are plural (ArticlesController), and Views match controller name (articles/index).

Q6: How do you pass data from controller to view?

A: Use instance variables (e.g., @article).

# Controller
      @article = Article.find(1)
      
      # View
      <%= @article.title %>

Q7: How do you fetch form input in controller?

A: Use params[:field_name].

def create
        title = params[:title]
      end

Q8: How do you define validations in models?

A: Use validates keyword.

validates :title, presence: true, uniqueness: true

Q9: What is strong parameter in Rails?

A: It’s used to whitelist allowed params.

params.require(:article).permit(:title, :body)

Q10: How do you render partial views?

A: Use render in view files.

<%= render 'form' %>

Q11: How do you handle 404 not found?

A: Use ActiveRecord::RecordNotFound rescue.

def show
        @article = Article.find(params[:id])
      rescue ActiveRecord::RecordNotFound
        redirect_to articles_path, alert: "Not found"
      end

Q12: How do you redirect in controller?

A: Use redirect_to method.

redirect_to articles_path, notice: "Article created!"

Q13: How do you render JSON from a controller?

A: Use render json:.

render json: @article

Q14: What is DRY principle in MVC?

A: “Don’t Repeat Yourself” — reuse partials, helpers, and concerns.

Q15: How do you organize logic that doesn’t belong in controller or model?

A: Use service objects or concerns.

Q16: How do you use helper methods in views?

A: Define methods in app/helpers.

module ArticlesHelper
        def format_date(date)
          date.strftime("%b %d, %Y")
        end
      end

Q17: What is the difference between render and redirect_to?

A: render shows a template without a new request. redirect_to sends a new request.

Q18: How do you share logic between multiple controllers?

A: Use controller concerns (mixins).

# app/controllers/concerns/auth_helper.rb
      module AuthHelper
        def current_user
          User.find(session[:user_id])
        end
      end

Q19: How to debug inside a controller?

A: Use byebug or Rails.logger.debug.

Rails.logger.debug "Here is params: #{params.inspect}"

Q20: What is the default folder structure in MVC?

A:

• app/models/ → contains model files
• app/controllers/ → controller logic
• app/views/ → HTML templates

✅ Best Practices

1. Keep Controllers Thin, Models Fat

Move most of the business logic to models or service objects. Controllers should only coordinate tasks.

# ❌ Bad: logic in controller
      def create
        user = User.new(params[:user])
        if user.age >= 18
          user.approved = true
        end
        user.save
      end
      
      # ✅ Good: move logic to model
      # app/models/user.rb
      def approve_if_adult
        self.approved = true if age >= 18
      end
      
      # controller
      def create
        user = User.new(user_params)
        user.approve_if_adult
        user.save
      end

2. Use Partial Views for Reusable HTML

Break your views into smaller components (called partials) to avoid repetition.

<%= render 'form' %>
      
      # app/views/articles/_form.html.erb
      <form>
        ...
      </form>

3. Use Strong Parameters for Security

Always whitelist params to avoid mass-assignment attacks.

params.require(:article).permit(:title, :content)

4. Follow RESTful Routes

Use standard routes and actions like index, show, create, update, and destroy.

resources :articles

5. DRY – Don’t Repeat Yourself

Use helpers, layouts, partials, and concerns to avoid writing the same code multiple times.

6. Validate Data in Models

Use built-in validations like presence, length, uniqueness, etc.

validates :email, presence: true, uniqueness: true

7. Use Flash Messages for Feedback

Let users know what’s happening (success, error, etc.).

redirect_to articles_path, notice: "Article saved!"

8. Handle Errors Gracefully

Use rescue_from or simple rescue blocks to handle exceptions without crashing the app.

rescue ActiveRecord::RecordNotFound
        redirect_to root_path, alert: "Not found."

9. Use Layouts for Consistent UI

Put common HTML (e.g., navbar, footer) in app/views/layouts/application.html.erb.

10. Organize Files Properly

Keep your code clean. For example:

• app/models/ – Business logic
• app/controllers/ – Request handling
• app/views/ – Presentation
• app/services/ – Extracted logic (optional)
• app/helpers/ – Reusable UI helpers

11. Write Tests

Use RSpec or Minitest to test models, controllers, and features.

# RSpec example
      describe Article do
        it "is valid with a title" do
          expect(Article.new(title: "Test")).to be_valid
        end
      end

12. Use Scopes for Query Logic

# app/models/article.rb
      scope :published, -> { where(published: true) }

13. Don’t Query in Views

Prepare all data in the controller.

# ❌ Bad
      <% Comment.where(article_id: article.id).each do |comment| %>
      
      # ✅ Good
      @comments = article.comments

14. Use before_action Filters

before_action :set_article, only: [:show, :edit, :update]

15. Use Helpers in Views, Not Logic

Format dates, texts, etc. using helpers.

<%= format_date(@article.created_at) %>

🌍 Real-World Use Cases

• Blog platforms
• Project management tools
• E-commerce platforms
• CRM systems

🧠 Detailed Explanation

Service Objects are plain Ruby classes that help us organize code when things get too messy in controllers or models.

In a Rails app, controllers are supposed to only handle **requests** and **responses**. Models are meant to deal with **data and validations**. But what if you need to do something more complex — like register a user, send a welcome email, and log the action?

That’s too much for one place — and that’s where a Service Object comes in!

It’s a class that does one job only, and does it well.

• 📦 It’s placed in the app/services folder
• 📞 You usually call it like: MyService.new(...).call
• ⚙️ Inside it, you can handle things like saving data, sending emails, calling APIs, etc.

Why use it?

• ✅ Keeps your controller short and clean
• ✅ Keeps your model focused on data
• ✅ Makes your code easier to read and test

Think of it like this:

• 🚕 Controller = Taxi driver (takes request)
• 🧾 Model = Address book (stores info)
• 🛠️ Service Object = GPS system (calculates best route and executes the task)

In short, **Service Objects help you write cleaner, organized, and reusable code** when logic becomes too complex for normal controllers or models.

📘 Key Terms & Best Concepts – Service Objects in Rails

🔁 Service Object Flow – Step by Step

1. 🧑‍💻 Controller receives a request
   User submits a form or sends an API call.
2. 📦 Controller creates a service object instance
   The controller passes the required data to the service.
   service = MyService.new(params)
3. 🚀 Controller calls the service
   The controller runs the service’s call method.
   result = service.call
4. ⚙️ Service runs business logic
   Service performs tasks like saving data, sending email, etc.
5. 📲 Controller handles result
   Based on the return value, the controller decides what to render or where to redirect.

✅ Clean flow:
Controller → Service Object → Business Logic → Return Result → Controller Response

📌 Where & How to Use Service Objects

Use Service Objects anytime your controller or model is doing too much. Here are the most common use cases:

🧠 Tip: If you’re writing “if this, then that, then this again…” in a controller — it’s time to use a Service Object.

🛠️ Best Implementation (Step-by-Step)

This example shows how to use a Service Object to register a user, send a welcome email, and log the activity — keeping the controller clean and logic reusable.

📁 1. Create a folder for services

If it doesn’t already exist, create a new folder in your Rails app:

mkdir app/services

📦 2. Create the Service Object

File: app/services/user_registration_service.rb

class UserRegistrationService
        def initialize(user_params)
          @user_params = user_params
        end
      
        def call
          user = User.new(@user_params)
      
          if user.save
            send_welcome_email(user)
            log_registration(user)
          end
      
          user
        end
      
        private
      
        def send_welcome_email(user)
          UserMailer.welcome_email(user).deliver_later
        end
      
        def log_registration(user)
          Rails.logger.info("User #{user.email} registered at #{Time.now}")
        end
      end

• ✅ Uses initialize to receive data
• ✅ Public call method performs the main task
• ✅ Private methods encapsulate side tasks (email, log)

🎮 3. Use in Controller

File: app/controllers/users_controller.rb

class UsersController < ApplicationController
        def create
          @user = UserRegistrationService.new(user_params).call
      
          if @user.persisted?
            redirect_to @user, notice: "Welcome!"
          else
            render :new
          end
        end
      
        private
      
        def user_params
          params.require(:user).permit(:name, :email, :password)
        end
      end

✅ Clean controller: All business logic is moved to the service.

📧 4. Create a Mailer (Optional)

If you don’t already have a mailer:

rails generate mailer UserMailer welcome_email

# app/mailers/user_mailer.rb
      class UserMailer < ApplicationMailer
        def welcome_email(user)
          @user = user
          mail(to: @user.email, subject: "Welcome to the platform!")
        end
      end

🧪 5. Add a Simple Test

# spec/services/user_registration_service_spec.rb
      require 'rails_helper'
      
      RSpec.describe UserRegistrationService do
        it "creates a user and sends email" do
          params = { name: "Ali", email: "[email protected]", password: "password" }
          service = described_class.new(params)
          user = service.call
      
          expect(user).to be_persisted
        end
      end

📝 Summary

• 📍 Create a class in app/services
• 🧼 Keep only one public method: call
• ⚙️ Move logic out of controller
• ✅ Test independently like any Ruby class

🎯 Result: Cleaner code, easier testing, reusable logic, and proper Rails architecture.

💡 Examples

# app/services/user_registration_service.rb
  class UserRegistrationService
    def initialize(user_params)
      @user_params = user_params
    end
  
    def call
      user = User.new(@user_params)
      if user.save
        UserMailer.welcome_email(user).deliver_later
      end
      user
    end
  end
  
  # controller
  def create
    @user = UserRegistrationService.new(user_params).call
  end

🧩 Gems & Libraries for Service Objects

🔁 Alternative Concepts

• Fat Models (not recommended for complex logic)
• Command Pattern
• Interactors (e.g., Interactor gem)
• Observers (for background triggers)

🛠️ Technical Questions & Answers

Q1: What is a Service Object in Rails?

A: A Service Object is a plain Ruby class that performs a single job, like processing a payment or registering a user.

# app/services/charge_payment.rb
      class ChargePayment
        def initialize(order)
          @order = order
        end
      
        def call
          PaymentGateway.charge(@order.amount)
        end
      end

Q2: What is the recommended method name in service objects?

A: Use a public method named call to keep consistency across services.

def call
        # perform action
      end

Q3: How do you use a service object in a controller?

A: Instantiate and call it with parameters.

@result = MyService.new(params).call

Q4: Where do you store service objects in a Rails app?

A: Inside the app/services directory.

Q5: How do you return errors from a service object?

A: Use a result object or add an @errors instance variable.

def call
        if some_failure?
          @errors = ["Something went wrong"]
          return false
        end
        true
      end

Q6: Can service objects trigger ActiveJob or mailers?

A: Yes, they are perfect for wrapping background jobs or email tasks.

def call
        UserMailer.welcome_email(user).deliver_later
      end

Q7: How do you test a service object?

A: Use a plain RSpec test or Minitest unit test.

# RSpec
      describe RegisterUser do
        it "creates user" do
          user = RegisterUser.new(params).call
          expect(user).to be_persisted
        end
      end

Q8: What are alternatives to service objects in Rails?

A: You can use:

• Interactor gem
• Form Objects
• Command Pattern manually

Q9: Can you return a model from a service?

A: Yes. Most services return a model, boolean, or response object.

def call
        user = User.create(@params)
        return user
      end

Q10: Can service objects use transactions?

A: Yes! Wrap related database calls inside ActiveRecord::Base.transaction.

def call
        ActiveRecord::Base.transaction do
          user.save!
          profile.save!
        end
      end

Q11: Should you include Rails helpers or sessions in a service?

A: No. Keep services pure. Don’t use controller-specific helpers or global state.

Q12: Can service objects raise errors?

A: Yes, but it’s better to handle errors gracefully and return a result or error message.

Q13: Can you inject dependencies in a service object?

A: Yes, you can inject collaborators through the constructor.

def initialize(order, payment_gateway = Stripe)
        @order = order
        @gateway = payment_gateway
      end

Q14: How do you chain service objects?

A: One service can call another service from within its call method.

def call
        result = CreateOrder.new(order_params).call
        SendInvoice.new(result).call
      end

Q15: Can you memoize values inside a service?

A: Yes, use instance variables.

def user
        @user ||= User.find(@user_id)
      end

✅ Best Practices with Examples

1. Name Service Objects with Verbs

Use names that describe the action being performed (e.g., CreateInvoice, RegisterUser, SendEmail).

# Good
      RegisterUser.new(user_params).call

2. Put Services in app/services/

This keeps your app organized and follows Rails conventions.

app/
        services/
          register_user.rb
          send_invoice.rb

3. Use a call Method

Always define a single public call method — this keeps usage consistent and readable.

def call
        # main logic
      end

4. Keep the Service Focused (Single Responsibility)

Each service should do only one thing. Don’t mix tasks.

# ✅ Good: One responsibility
      class RegisterUser
        def call
          create_user
          send_welcome_email
        end
      end

5. Return a Value (Model, Boolean, Result Object)

This makes the service predictable and testable.

def call
        user = User.new(...)
        user.save
        user
      end

6. Use Private Methods for Subtasks

Keep the call method short by splitting complex steps into private methods.

def call
        create_user
        notify_user
      end
      
      private
      
      def create_user
        ...
      end

7. Don’t Use Controller Stuff (params, session)

Extract what you need in the controller, then pass it in. Keep services pure Ruby.

# Controller
      RegisterUser.new(user_params).call

8. Use Transactions if Multiple DB Writes

Prevent partial saves by wrapping logic inside a transaction.

def call
        ActiveRecord::Base.transaction do
          user.save!
          profile.save!
        end
      end

9. Handle Errors Inside the Service

Don’t leak logic errors to the controller — return false, a message, or raise a handled error.

def call
        return false unless valid_input?
      
        do_something
      end

10. Write Tests for Each Service

Since services are plain Ruby classes, they are easy to test with RSpec or Minitest.

describe SendWelcomeEmail do
        it "delivers the email" do
          result = SendWelcomeEmail.new(user).call
          expect(result).to be_truthy
        end
      end

🌍 Real-World Use Cases

• 📬 Sending confirmation or welcome emails
• 💳 Handling third-party payment gateway logic
• 📊 Generating downloadable reports or exports
• 📦 Placing an order and charging the customer
• 🎟️ Ticket booking workflows

🧠 Detailed Explanation

Form Objects are Ruby classes that help you manage form input when:

• ✅ You need to use one form to save/update **multiple models**
• ✅ You want to validate form data **before** saving it
• ✅ You don’t want to bloat your **controller or models** with form-specific logic

Rails models (like User) are great when your form matches one table. But what if you have a signup form that:

• Collects user name and email (User model)
• Sends a welcome email (Mailer)
• Logs the action (Logger)

That’s too much for one model or controller! 🎯 This is where a Form Object shines.

It acts like a model but doesn’t save to the database directly. Instead, it:

1. Collects the form data
2. Validates it
3. Then saves or updates the real models inside its save method

How?

class SignupForm
        include ActiveModel::Model
      
        attr_accessor :name, :email, :password
      
        validates :name, :email, :password, presence: true
      
        def save
          return false unless valid?
          User.create(name: name, email: email, password: password)
        end
      end

Why it’s useful:

• 🧼 Keeps controller actions short
• 📦 Keeps models focused on data only
• 🔍 Easy to test like any Ruby class

Think of it like:

• 🧾 A translator between your form and your models
• 🛠 A one-stop tool that collects, checks, and passes on the data

Bonus: Form objects also make writing multi-step forms or wizard-style pages way easier!

🔁 How Form Objects Work (Step-by-Step Flow)

1. 👤 User submits a form
   For example, a signup or checkout form in your app.
2. 📦 Controller initializes a form object
   The controller passes form values to a class like SignupForm.new(params).
3. ✅ Form object validates the input
   It uses ActiveModel::Validations to check if everything is okay.
4. 💾 Form object runs logic inside save
   If the data is valid, it creates or updates one or more models, sends an email, etc.
5. 📲 Controller redirects or renders based on result
   If successful: redirect to dashboard. If failed: render the form with errors.

Typical Flow:

Form Submit → Controller → Form Object → Validate + Save → Return Result

📌 Where & How to Use Form Objects

Form Objects are best when your form is doing more than just saving one table (model). Here’s when and where to use them:

🧠 Rule of Thumb:
If your form:

• Touches more than one model, OR
• Is not tied directly to a database table

➡️ Then it’s a good candidate for a Form Object.

📘 Key Terms & Concepts – Form Objects in Rails

🧩 Gems & Libraries for Form Objects in Rails

🛠️ Best Implementation – Full Walkthrough

This example demonstrates how to build a Signup Form using a Form Object in a Rails app. The form collects user details and handles validation, user creation, and welcome email delivery — cleanly separated from the controller.

📦 Step 1: Create a Form Object

File: app/forms/signup_form.rb

class SignupForm
        include ActiveModel::Model
      
        attr_accessor :name, :email, :password
      
        validates :name, :email, :password, presence: true
        validates :email, format: { with: URI::MailTo::EMAIL_REGEXP }
      
        def save
          return false unless valid?
      
          user = User.create(
            name: name,
            email: email,
            password: password
          )
      
          send_welcome_email(user)
          user
        end
      
        private
      
        def send_welcome_email(user)
          UserMailer.welcome_email(user).deliver_later
        end
      end

• ✅ Uses ActiveModel::Model to behave like a Rails model
• 🧪 Validations ensure the form data is correct before creating the user
• 🔧 Custom logic inside save creates the user and sends email

🎮 Step 2: Use It in a Controller

File: app/controllers/registrations_controller.rb

class RegistrationsController < ApplicationController
        def new
          @form = SignupForm.new
        end
      
        def create
          @form = SignupForm.new(signup_params)
      
          if @form.save
            redirect_to dashboard_path, notice: "Welcome!"
          else
            render :new
          end
        end
      
        private
      
        def signup_params
          params.require(:signup_form).permit(:name, :email, :password)
        end
      end

• 🧼 Clean controller: business logic is inside the form object
• 🔥 Uses the form object like a model (form_with model: @form)

📝 Step 3: Build the Form in the View

File: app/views/registrations/new.html.erb

<%= form_with model: @form, url: registrations_path, local: true do |f| %>
        <div>
          <%= f.label :name %>
          <%= f.text_field :name %>
        </div>
      
        <div>
          <%= f.label :email %>
          <%= f.email_field :email %>
        </div>
      
        <div>
          <%= f.label :password %>
          <%= f.password_field :password %>
        </div>
      
        <%= f.submit "Sign Up" %>
      <% end %>

✅ Looks and behaves like a model-backed form even though it’s a plain Ruby class.

🧪 Step 4: Test the Form Object (RSpec)

File: spec/forms/signup_form_spec.rb

require 'rails_helper'
      
      RSpec.describe SignupForm, type: :model do
        it "is valid with valid data" do
          form = SignupForm.new(name: "Ali", email: "[email protected]", password: "password")
          expect(form.valid?).to be true
        end
      
        it "is invalid without a name" do
          form = SignupForm.new(email: "[email protected]", password: "pass")
          expect(form.valid?).to be false
        end
      
        it "saves and creates a user" do
          form = SignupForm.new(name: "Ali", email: "[email protected]", password: "password")
          user = form.save
          expect(user).to be_a(User)
          expect(user.persisted?).to be true
        end
      end

📝 Summary

• 📁 Organize form logic inside app/forms
• 📦 Use ActiveModel::Model to gain validations and model-like behavior
• 🧠 Define a single save method for all logic (validation + model updates)
• 🎯 Keeps controller and model clean and focused
• 🧪 Easy to test — just like a regular Ruby class

💡 Examples

File: app/forms/signup_form.rb

class SignupForm
    include ActiveModel::Model
  
    attr_accessor :name, :email, :password
  
    validates :name, :email, :password, presence: true
  
    def save
      return false unless valid?
  
      user = User.create(name: name, email: email, password: password)
      WelcomeMailer.send_email(user).deliver_later
    end
  end

Controller usage:

def create
    @form = SignupForm.new(signup_params)
  
    if @form.save
      redirect_to dashboard_path
    else
      render :new
    end
  end

🔁 Alternative Concepts

• Using only ActiveRecord models (not good for complex forms)
• Service Objects for non-form related logic
• Reform gem (provides a DSL for form objects)

🛠️ Technical Q&A with Examples – Form Objects in Rails

Q1: What is a Form Object in Rails?

A: A Form Object is a plain Ruby class that handles form input, validations, and saves one or more models.

class ContactForm
        include ActiveModel::Model
      
        attr_accessor :name, :email
      
        validates :name, :email, presence: true
      end

Q2: Why use Form Objects instead of ActiveRecord models?

A: Use them when your form:

• Is not directly tied to one table
• Needs to update/create multiple models
• Has validations but no persistence

Q3: How do you validate data in a Form Object?

A: Use ActiveModel::Validations (comes with ActiveModel::Model).

validates :email, presence: true, format: { with: URI::MailTo::EMAIL_REGEXP }

Q4: How do you trigger logic after validation in a Form Object?

A: Add a custom save method and call it from the controller.

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

Q5: Where should Form Objects be placed in a Rails app?

A: Best practice is to place them in app/forms/.

Q6: Can I use form_with model: with a Form Object?

A: Yes, if the object includes ActiveModel::Model and defines persisted? (even returning false).

def persisted?
        false
      end

Q7: How do I save multiple models inside a Form Object?

A: Just write custom logic in save to update or create each model.

def save
        return false unless valid?
        user = User.create!(email: email)
        profile = Profile.create!(user: user, bio: bio)
      end

Q8: How do I test a Form Object?

A: You write unit tests like any Ruby class — no need to touch the database unless models are used.

describe SignupForm do
        it "is valid with name and email" do
          form = SignupForm.new(name: "Ali", email: "[email protected]")
          expect(form.valid?).to be true
        end
      end

Q9: Can I reuse form logic in multiple controllers?

A: Yes! That’s one of the key benefits — form objects are portable and reusable.

Q10: How do I show validation errors from a Form Object?

A: Same as regular models. Use @form.errors.full_messages in the view.

<% @form.errors.full_messages.each do |msg| %>
        <div class="error"><%= msg %></div>
      <% end %>

✅ Best Practices with Examples

1. Use ActiveModel::Model to behave like a Rails model

This gives your Form Object access to validations, form compatibility, and error handling.

class ContactForm
        include ActiveModel::Model
        attr_accessor :name, :email
        validates :name, :email, presence: true
      end

2. Place form objects in app/forms/

Keep your app organized by following a consistent structure.

app/
        forms/
          signup_form.rb
          contact_form.rb

3. Use attr_accessor to define form fields

This simulates model attributes and makes form binding work.

attr_accessor :email, :message

4. Define a save method to control what happens on submission

Keep validations and logic separate from the controller.

def save
        return false unless valid?
        Message.create(email: email, body: message)
      end

5. Use form_with model: for easy view integration

Form objects work just like models in forms.

<%= form_with model: @form, url: messages_path do |f| %>
        <%= f.text_field :email %>
        <%= f.text_area :message %>
      <% end %>

6. Avoid database logic in the controller

Let the form object handle validations and model persistence.

# Controller
      @form = ContactForm.new(params[:contact_form])
      if @form.save
        redirect_to root_path
      else
        render :new
      end

7. Use persisted? to avoid errors in views

If you’re not using ActiveRecord, return false.

def persisted?
        false
      end

8. Combine multiple models in the save method

Handle user + profile creation in one form.

def save
        return false unless valid?
        user = User.create!(email: email)
        Profile.create!(user: user, bio: bio)
      end

9. Write unit tests for form objects

Since they don’t depend on the database, they’re easy to test.

describe ContactForm do
        it "is invalid without an email" do
          form = ContactForm.new(message: "Hello")
          expect(form.valid?).to be false
        end
      end

10. Don’t overload with business logic

Form objects are for validation and model coordination — not for large-scale workflows. Use a service object for those.

🌍 Real-World Use Cases

• 📝 Signup forms that require creating a user and sending an email
• 👥 Profile forms that update both user and address models
• 📋 Multi-step wizards (like job applications or onboarding)
• 🛒 Checkout forms that handle orders, payment info, and address

🧠 Detailed Explanation

Query Objects are plain Ruby classes that hold your complex database queries in one place — instead of stuffing them inside controllers or models.

They help you answer questions like:

• 🔍 “Who are our most active users this month?”
• 📦 “What orders were delayed last week?”
• 📊 “What are the top 10 products by sales in the last 30 days?”

Instead of writing this logic in the model or repeating it everywhere, you create a query class that does it once and cleanly.

Think of it like:

• 🧠 A smart question that knows how to get the answer from your database
• 📁 A reusable search tool you can call anytime
• 🧼 A clean way to move complicated ActiveRecord chains out of your models

Here’s a simple example:

# app/queries/active_users_query.rb
      class ActiveUsersQuery
        def initialize(days = 30)
          @days = days
        end
      
        def call
          User.where(active: true)
              .where("last_login_at >= ?", @days.days.ago)
        end
      end

How to use it:

active_users = ActiveUsersQuery.new(7).call

Why it’s helpful:

• ✅ Reuse the same query in multiple places
• ✅ Easier to test — no Rails controller or view needed
• ✅ Keeps your models and controllers clean

Bonus: If your query returns an ActiveRecord::Relation, you can still chain it like:

ActiveUsersQuery.new(7).call.order(:created_at).limit(10)

📦 In short, Query Objects help you write better, cleaner, and more powerful queries — without cluttering your models or controllers.

📘 Key Terms & Concepts – Query Objects in Rails

🔁 How Query Objects Work (Flow)

1. 🧠 You identify a complex or repeating query
   Example: active users in the last 7 days, top orders, inactive customers.
2. 📦 You create a Query Object class
   Located in app/queries and named like ActiveUsersQuery.
3. 🛠️ Inside the class, you define a call method
   It contains the query logic and returns the result.
4. 📲 You use it wherever needed
   Controller, service object, job, API response — just call:
   ActiveUsersQuery.new.call
5. ✅ Query Object returns a relation or result
   You get filtered, scoped, testable results — clean and easy.

Summary:

Feature Need → Create Query Object → Write call → Use Anywhere → Maintain Easily

📌 Where & How to Use Query Objects

Use Query Objects when your query is:

• 🔁 Repeated in multiple places
• 📏 Getting too long or complex
• 🧪 Needs to be tested separately
• 🎯 Has dynamic parameters (e.g., date ranges, roles)

Common Areas to Use Query Objects in Rails:

🧠 Rule: If your query has logic + filters + repetition → move it to a Query Object.

🧩 Gems & Libraries for Query Objects in Rails

🛠️ Best Implementation – Query Object Step-by-Step

This example demonstrates how to implement a Query Object to find users who logged in during the last N days. The goal is to keep this logic reusable, testable, and out of the controller or model.

📁 Step 1: Create a Folder for Query Objects

If it doesn’t exist already, create:

mkdir app/queries

📦 Step 2: Create a Query Object Class

File: app/queries/active_users_query.rb

class ActiveUsersQuery
        def initialize(days = 30)
          @days = days
        end
      
        def call
          User.where(active: true)
              .where("last_login_at >= ?", @days.days.ago)
              .order(last_login_at: :desc)
        end
      end

• ✅ Uses plain Ruby class
• 🧪 Encapsulates logic inside a clean call method
• 📦 Accepts parameters like days for flexibility
• 🔁 Returns a relation for chaining and efficient queries

🎮 Step 3: Use in a Controller

File: app/controllers/admin/users_controller.rb

class Admin::UsersController < ApplicationController
        def index
          @active_users = ActiveUsersQuery.new(14).call
        end
      end

✅ Benefit: Your controller stays short and readable.

🧪 Step 4: Write a Test for the Query Object

File: spec/queries/active_users_query_spec.rb

require "rails_helper"
      
      RSpec.describe ActiveUsersQuery do
        it "returns users logged in within given days" do
          old_user = create(:user, active: true, last_login_at: 60.days.ago)
          recent_user = create(:user, active: true, last_login_at: 2.days.ago)
          create(:user, active: false, last_login_at: 1.day.ago)
      
          result = described_class.new(7).call
      
          expect(result).to include(recent_user)
          expect(result).not_to include(old_user)
          expect(result).to all(be_active)
        end
      end

🧪 Benefit: Queries are now testable in isolation — no need to spin up the full controller.

📝 Summary – Key Concepts Used

• ✅ Plain Ruby class, no external dependencies
• 📦 Located in app/queries/
• 🧼 One clear responsibility: a specific reusable query
• 🧪 Testable like any service or model
• ♻️ Reusable across controllers, jobs, mailers, and services

Pro Tip: Keep all your query objects consistent — name them with Query suffix and expose only one method: call.

💡 Example

File: app/queries/active_users_query.rb

class ActiveUsersQuery
    def initialize(recent_days = 30)
      @recent_days = recent_days
    end
  
    def call
      User.where(active: true)
          .where("last_login_at >= ?", @recent_days.days.ago)
    end
  end

Usage in controller or service:

active_users = ActiveUsersQuery.new(14).call

🔁 Alternative Concepts

• Named scopes in the model (less flexible)
• Service Objects with query logic inside (not ideal separation)
• Class methods inside models (tighter coupling)

🛠️ Technical Q&A – Query Objects in Rails

Q1: What is a Query Object in Rails?

A: A Query Object is a plain Ruby class used to extract and organize complex or reusable database queries outside of the model or controller.

# app/queries/active_users_query.rb
      class ActiveUsersQuery
        def call
          User.where(active: true)
        end
      end

Q2: What method do you use to trigger a Query Object?

A: Conventionally, Query Objects expose a single public method called call.

ActiveUsersQuery.new.call

Q3: Why use Query Objects instead of model scopes?

A: Use Query Objects when queries become too complex, have multiple conditions, or need parameters — keeping your model clean and adhering to SRP (Single Responsibility Principle).

# Too much in model
      scope :active_recent, ->(days) {
        where(active: true).where("last_login_at >= ?", days.days.ago)
      }
      
      # ✅ Cleaner in query object
      class ActiveUsersQuery
        def initialize(days = 30); @days = days; end
        def call
          User.where(active: true).where("last_login_at >= ?", @days.days.ago)
        end
      end

Q4: Where should you store Query Objects in Rails?

A: The recommended location is app/queries.

Q5: What should a Query Object return?

A: Preferably an ActiveRecord::Relation so you can chain it with pagination, ordering, etc.

TopOrdersQuery.new.call.limit(5)

Q6: Can you pass parameters to Query Objects?

A: Yes! Accept parameters through initialize and use them in the call method.

class OrdersByStatusQuery
        def initialize(status)
          @status = status
        end
      
        def call
          Order.where(status: @status)
        end
      end

Q7: How do you test a Query Object?

A: Like any Ruby class — test the output of call based on created data.

describe ActiveUsersQuery do
        it "returns only active users" do
          active = create(:user, active: true)
          inactive = create(:user, active: false)
          result = ActiveUsersQuery.new.call
          expect(result).to include(active)
          expect(result).not_to include(inactive)
        end
      end

Q8: Can Query Objects be composed (combined)?

A: Yes, if they return ActiveRecord::Relation. You can pass one object’s result to another.

recent_orders = RecentOrdersQuery.new.call
      shipped_orders = recent_orders.where(status: 'shipped')

Q9: Should Query Objects contain business logic?

A: No — they should only contain database access logic (queries). Business rules belong in service objects or models.

Q10: What are the benefits of Query Objects?

A:

• 🧼 Cleaner controller and model
• 🔁 Reusable across the app
• 🧪 Easier to test
• 💡 More readable and flexible query structure

✅ Best Practices with Examples

1. Use the Query suffix in class names

This makes it clear the class is responsible for fetching data.

# ✅ Good
      TopUsersQuery
      ActiveOrdersQuery

2. Put all Query Objects in app/queries

Keep your folder structure organized.

app/
        queries/
          active_users_query.rb
          recent_orders_query.rb

3. Only expose one public method: call

Keep a simple interface across all query objects.

def call
        # return relation or data
      end

4. Always return ActiveRecord::Relation if possible

This allows further chaining, like pagination, sorting, etc.

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

5. Accept dynamic parameters via initialize

Make your query objects flexible and reusable.

class OrdersByStatusQuery
        def initialize(status)
          @status = status
        end
      
        def call
          Order.where(status: @status)
        end
      end

6. Keep business logic out of Query Objects

Query objects should focus only on data retrieval — not side effects.

# ❌ Bad
      def call
        orders = Order.where(status: 'paid')
        EmailService.send_alert(orders)  # 👎
      end

7. Write unit tests for each query object

Query Objects are easy to test because they are isolated and pure.

describe RecentPostsQuery do
        it "returns posts from last 7 days" do
          post = create(:post, created_at: 3.days.ago)
          old_post = create(:post, created_at: 30.days.ago)
          result = described_class.new(7).call
          expect(result).to include(post)
          expect(result).not_to include(old_post)
        end
      end

8. Chainable Query Objects are best

If you return a relation, you can chain, paginate, and reuse more easily.

TopUsersQuery.new.call.limit(10).page(1)

9. Use descriptive method names if returning multiple queries

But default to call if you only need one interface.

def by_country; ... end
      def by_status; ... end

10. Compose multiple Query Objects if needed

You can pass one query result into another to keep things modular.

verified = VerifiedUsersQuery.new.call
      admin_verified = verified.where(role: 'admin')

🌍 Real-World Use Cases

• 🧍‍♂️ Fetching active or premium users
• 🛍 Getting top-selling products in the last 30 days
• 📦 Orders with delayed shipments
• 🔎 Custom admin dashboard filters
• 📊 Reusable analytics filters for reports

🧠 Detailed Explanation

The Decorator Pattern is a way to add extra features or formatting to an object — without changing the object itself.

In Rails, we use decorators to format data for the view without cluttering the model or the controller.

Imagine you have a User model with first_name and last_name. You want to show the full name like “Ali Khan” in the view — but you don’t want to add a method like full_name inside the model. That’s where a decorator helps!

It wraps your model and adds view-specific logic like formatting names, dates, prices, etc.

🔧 What does it look like?

# user_decorator.rb
      class UserDecorator
        def initialize(user)
          @user = user
        end
      
        def full_name
          "#{@user.first_name} #{@user.last_name}"
        end
      
        def joined_on
          @user.created_at.strftime("%B %d, %Y")
        end
      end

🧠 How is it used?

@decorated_user = UserDecorator.new(@user)
      @decorated_user.full_name  # "Ali Khan"
      @decorated_user.joined_on  # "May 24, 2025"

🎯 Why is it useful?

• ✅ Keeps your models clean — no view logic inside
• ✅ Keeps your views readable — no long formatting code
• ✅ Follows Single Responsibility Principle — formatting belongs in decorators
• ✅ Easy to test — decorators are plain Ruby classes

🔁 Think of it like:

• 📦 A “wrapper” that gives the same object extra powers
• 🎨 A presentation layer that’s separate from your business logic
• 📺 A TV remote that doesn’t change the TV — it just gives you a better way to interact with it

Decorator Pattern = Your model + display logic, cleanly separated.

📘 Key Terms & Concepts – Decorator Pattern in Rails

🔁 How the Decorator Pattern Works

1. 🧱 You have a model
   Example: User model with first_name and last_name.
2. 🎨 You want to display it differently in the view
   Like showing full_name or a formatted date.
3. 📦 You create a decorator class
   This class wraps the model and adds custom formatting or display methods.
4. 🔁 You use the decorator in the controller or view
   Instead of calling @user.name, you call @decorated_user.full_name.
5. ✅ The view stays clean, the model stays clean, and your logic is testable

Model ➝ Decorator ➝ View
      (User)   (UserDecorator)   (user.full_name)

📌 Where & How to Use Decorators in Rails

Decorators are best used when you want to format or prepare data for display, without bloating your model or view files.

🧠 Rule: If it’s only needed for views and formatting, use a decorator — not a model or helper.

🧩 Gems & Libraries for the Decorator Pattern

🛠️ Best Implementation – Using SimpleDelegator (Native Ruby)

Goal: Display a user’s full name and nicely formatted join date without polluting the model or the view.

📁 Step 1: Create the Decorator File

File: app/decorators/user_decorator.rb

require 'delegate'
      
      class UserDecorator < SimpleDelegator
        def full_name
          "#{first_name} #{last_name}"
        end
      
        def joined_date
          created_at.strftime("%B %d, %Y")
        end
      end

• ✅ SimpleDelegator auto-forwards all methods to the original object
• 🧼 Only enhanced presentation logic lives here

🎮 Step 2: Wrap the Model in the Controller

# app/controllers/users_controller.rb
      def show
        @user = User.find(params[:id])
        @user = UserDecorator.new(@user)
      end

✅ Now @user.full_name and @user.joined_date are available in the view.

🖼️ Step 3: Use in the View

<p>Welcome, <%= @user.full_name %></p>
      <p>Joined on: <%= @user.joined_date %></p>

🧪 Step 4: Test the Decorator

# spec/decorators/user_decorator_spec.rb
      describe UserDecorator do
        it "returns full name" do
          user = User.new(first_name: "Ali", last_name: "Khan", created_at: Time.new(2024, 5, 1))
          decorated = UserDecorator.new(user)
          expect(decorated.full_name).to eq("Ali Khan")
          expect(decorated.joined_date).to eq("May 01, 2024")
        end
      end

✅ Easy to test, no database needed!

🛠️ Best Implementation – Using Draper Gem

Use Draper when you need decorators with access to Rails view helpers (like number_to_currency, link_to, etc.).

🔧 Step 1: Install Draper

bundle add draper
      rails generate decorator User

📁 Step 2: Add Display Logic

# app/decorators/user_decorator.rb
      class UserDecorator < Draper::Decorator
        delegate_all
      
        def full_name
          "#{object.first_name} #{object.last_name}"
        end
      
        def joined_date
          h.time_ago_in_words(object.created_at) + " ago"
        end
      end

h gives you access to Rails view helpers inside the decorator.

🎮 Step 3: Decorate the Model

# users_controller.rb
      def show
        @user = User.find(params[:id]).decorate
      end

🖼️ Step 4: Use in the View

<p><%= @user.full_name %></p>
      <p>Joined: <%= @user.joined_date %></p>

💎 Optional: Automatically Decorate in Views

# config/application.rb
      config.to_prepare do
        ApplicationController.helper Draper::HelperSupport
      end

This allows you to call @user.full_name in views even without decorating in the controller.

💡 Example

File: app/decorators/user_decorator.rb

class UserDecorator
    def initialize(user)
      @user = user
    end
  
    def full_name
      "#{@user.first_name} #{@user.last_name}"
    end
  
    def formatted_join_date
      @user.created_at.strftime("%B %d, %Y")
    end
  end

Usage in view/controller:

@decorated_user = UserDecorator.new(@user)
  @decorated_user.full_name

🔁 Alternatives

• Helpers (good for simple formatting, not object-oriented)
• View Models (broader presentation objects)
• Presenter Pattern (similar but usually combines multiple models)

🛠️ Technical Q&A with Examples – Decorator Pattern in Rails

Q1: What is the purpose of a decorator in Rails?

A: To wrap a model and add presentation logic (like formatting or computed values) without modifying the model itself.

Q2: How do you create a decorator using Ruby only?

A: Use Ruby’s SimpleDelegator to forward all method calls to the original object.

class UserDecorator < SimpleDelegator
        def full_name
          "#{first_name} #{last_name}"
        end
      end
      
      decorated = UserDecorator.new(User.find(1))
      decorated.full_name

Q3: What’s the difference between a decorator and a presenter?

A: A decorator formats one object. A presenter often combines multiple objects or prepares data for a full view.

Q4: How can a decorator access Rails view helpers?

A: Use the Draper gem. It provides a helper proxy via h.

def formatted_price
        h.number_to_currency(object.total)
      end

Q5: How do you test a decorator?

A: Like any Ruby object. Pass a model and assert decorated output.

it "formats full name" do
        user = User.new(first_name: "Ali", last_name: "Khan")
        decorator = UserDecorator.new(user)
        expect(decorator.full_name).to eq("Ali Khan")
      end

Q6: Where should decorators be stored in a Rails app?

A: Conventionally, in app/decorators/.

Q7: What does delegate_all do in Draper?

A: It tells the decorator to forward all methods to the original model unless explicitly overridden.

Q8: Can decorators be used in collections?

A: Yes. With Draper: @users = User.all.decorate. For custom, use map { |u| UserDecorator.new(u) }.

Q9: What type of logic should NOT go into decorators?

A: Business logic, database queries, or persistence — keep those in models or services.

Q10: When should you choose a decorator over a helper?

A: Use a decorator when formatting is tied to an object instance and benefits from method chaining and encapsulation.

✅ Best Practices with Examples – Decorator Pattern in Rails

1. Use decorators for view-specific logic only

Decorators should format data — not handle business rules or persistence.

# Good
      def full_name
        "#{first_name} #{last_name}"
      end
      
      # Bad
      def save_user
        user.save  # ❌ belongs in model or service
      end

2. Store decorators in app/decorators

Keep your app clean and easy to navigate.

# File path:
      app/decorators/user_decorator.rb

3. Always name decorators with *Decorator suffix

Clear and searchable naming makes code self-documenting.

# Good
      UserDecorator, OrderDecorator
      
      # Bad
      UserViewHelper, FormattedUser

4. Delegate unknown methods to the wrapped model

Use SimpleDelegator or delegate_all (Draper) to make your decorator act like the model.

class ProductDecorator < SimpleDelegator
        def formatted_price
          "$#{'%.2f' % price}"
        end
      end

5. Don’t decorate in the view — decorate in the controller

Keep logic centralized and consistent.

# Good (controller)
      @user = UserDecorator.new(User.find(params[:id]))
      
      # Bad (view)
      UserDecorator.new(@user).full_name

6. Use Draper when you need helpers like number_to_currency

Draper provides a clean interface to view helpers through the h object.

def total_price
        h.number_to_currency(order.total)
      end

7. Avoid heavy logic or conditional trees

Keep decorators focused on formatting and readability.

# ✅ Keep it clean
      def status_label
        order.status.titleize
      end

8. Use decorators for collections when needed

@decorated_users = @users.map { |u| UserDecorator.new(u) }

9. Test decorators in isolation

You don’t need the full Rails stack to test them.

it "returns full name" do
        user = User.new(first_name: "Ali", last_name: "Khan")
        decorated = UserDecorator.new(user)
        expect(decorated.full_name).to eq("Ali Khan")
      end

10. Chain decorators or combine them in presenters when necessary

For multi-model views, consider using presenters or view objects composed of multiple decorators.

🌍 Real-World Use Cases

• 🧾 Formatting invoice totals with currency and tax
• 👤 Displaying user profile info like “Full Name” or “Joined on…”
• 📅 Formatting date ranges for events
• 📦 Showing shipping status based on delivery logic
• 💬 Showing time ago like “3 hours ago” using time_ago_in_words

🧠 Detailed Explanation

The Policy Pattern is used in Rails to control what actions a user is allowed to perform on a resource (like a post, comment, or order).

It’s part of the authorization system, which answers the question:

“Is this user allowed to do this?”

Instead of writing permission logic in your controllers or models, the policy pattern puts that logic in a separate file called a Policy.

Each model (like Post) can have a matching PostPolicy class. That class has methods like:

• show?
• update?
• destroy?

These methods return true or false depending on whether the user can do the action.

🔧 Example

# app/policies/post_policy.rb
      class PostPolicy
        attr_reader :user, :post
      
        def initialize(user, post)
          @user = user
          @post = post
        end
      
        def update?
          user.admin? || user == post.author
        end
      
        def destroy?
          user.admin?
        end
      end

📦 How it works

1. You create a policy class (e.g., PostPolicy)
2. Inside that class, you define methods like update?
3. In your controller, you write authorize @post
4. Rails checks if PostPolicy#update? returns true

# Controller
      def update
        @post = Post.find(params[:id])
        authorize @post  # checks if current_user can update it
        @post.update(post_params)
      end

✅ Why it’s useful

• 💡 Keeps authorization logic out of controllers
• 🧪 Easy to test (each policy is a plain Ruby class)
• 🔁 Reusable — use the same logic across controllers and views
• 📦 Clean and consistent structure for all models

Summary: The Policy Pattern lets you keep all your “who can do what” logic in one clean place — separate from models and controllers.

📘 Key Terms & Concepts – Policy Pattern (Authorization) in Rails

🔁 Flow – How the Policy Pattern Works

1. 🧱 A user triggers a controller action
   Example: Clicking “Edit Post” sends a request to the update action.
2. 🔐 The controller calls authorize
   This checks if the current user is allowed to perform that action using the corresponding policy.
3. 📄 The policy class is loaded
   Rails looks for a matching policy class (e.g., PostPolicy).
4. ✅ The relevant method is called
   For authorize @post inside update, Rails calls PostPolicy#update?.
5. 🔁 The method returns true or false
   Based on the logic inside the policy, the action is either allowed or denied.
6. 🚫 If false, Rails raises an authorization error
   You can handle this with a rescue block or error page.

# Controller
      def update
        @post = Post.find(params[:id])
        authorize @post  # calls PostPolicy#update?
        @post.update(post_params)
      end

📌 Where & How to Use Policy Pattern

Use the Policy Pattern whenever you want to control who can do what in your app. It separates authorization rules from your controllers and models.

💡 Pro Tip: Use the Policy Pattern anytime your logic includes “only if user is X” or “unless admin” conditions.

🧩 Gems & Libraries for Policy Pattern in Rails

🛠️ Best Implementation – Policy Pattern with Pundit (Rails)

This guide shows how to implement the Policy Pattern for a Post model, allowing only admins or post authors to update or delete a post.

🔧 Step 1: Install Pundit

bundle add pundit

Then run:

rails generate pundit:install

This adds ApplicationPolicy and includes Pundit in your ApplicationController.

📄 Step 2: Create a Policy for the Model

File: app/policies/post_policy.rb

class PostPolicy < ApplicationPolicy
        attr_reader :user, :post
      
        def initialize(user, post)
          @user = user
          @post = post
        end
      
        def update?
          user.admin? || user == post.author
        end
      
        def destroy?
          user.admin?
        end
      
        def show?
          true  # public post
        end
      end

✅ Note: Each method ends with ? and returns true or false.

🎮 Step 3: Use authorize in the Controller

File: app/controllers/posts_controller.rb

class PostsController < ApplicationController
        include Pundit
      
        def update
          @post = Post.find(params[:id])
          authorize @post  # Calls PostPolicy#update?
          @post.update(post_params)
          redirect_to @post, notice: "Updated!"
        end
      
        def destroy
          @post = Post.find(params[:id])
          authorize @post  # Calls PostPolicy#destroy?
          @post.destroy
          redirect_to posts_path, notice: "Deleted!"
        end
      end

✅ Pro Tip: Use authorize in every action that modifies data.

🧪 Step 4: Test the Policy Class

File: spec/policies/post_policy_spec.rb (RSpec)

RSpec.describe PostPolicy do
        let(:admin) { User.new(role: "admin") }
        let(:author) { User.new(id: 1) }
        let(:other_user) { User.new(id: 2) }
        let(:post) { Post.new(author: author) }
      
        subject { described_class }
      
        it "allows admin to update" do
          expect(subject.new(admin, post).update?).to be true
        end
      
        it "allows author to update" do
          expect(subject.new(author, post).update?).to be true
        end
      
        it "denies other user" do
          expect(subject.new(other_user, post).update?).to be false
        end
      end

🛡️ Step 5: Handle Unauthorized Access Gracefully

# application_controller.rb
      rescue_from Pundit::NotAuthorizedError, with: :user_not_authorized
      
      private
      
      def user_not_authorized
        flash[:alert] = "Access denied!"
        redirect_to(request.referer || root_path)
      end

✅ This shows a friendly message when access is denied.

📊 Bonus: Use Policy Scopes for Index Actions

File: post_policy.rb

class PostPolicy < ApplicationPolicy
        class Scope < Scope
          def resolve
            user.admin? ? scope.all : scope.where(published: true)
          end
        end
      end

In controller:

@posts = policy_scope(Post)

✅ Now users only see what they’re allowed to see.

💡 Example

Policy File: app/policies/post_policy.rb

class PostPolicy
    attr_reader :user, :post
  
    def initialize(user, post)
      @user = user
      @post = post
    end
  
    def update?
      user.admin? || user == post.author
    end
  
    def destroy?
      user.admin?
    end
  end

Usage in controller:

def update
    @post = Post.find(params[:id])
    authorize @post  # Will call PostPolicy#update?
    @post.update(post_params)
  end

🔁 Alternative Methods

• CanCanCan: Uses ability files but tightly couples authorization logic to models.
• Rolify: Adds roles, but doesn’t define logic per action.
• before_action: Works, but leads to scattered logic and duplication.

🛠️ Technical Questions & Answers – Policy Pattern (Rails + Pundit)

Q1: What is a policy in Rails?

A: A policy is a class that defines user permissions for actions on a model (e.g., update?, destroy?).

class PostPolicy
        def update?
          user.admin? || user == post.author
        end
      end

Q2: How does authorize work?

A: It automatically finds the related policy (e.g., PostPolicy) and checks the action (e.g., update?).

# In controller
      authorize @post  # Calls PostPolicy#update?

Q3: Where should policies be placed in a Rails app?

A: In app/policies/. Rails will auto-load them if the naming matches.

Q4: What is policy_scope used for?

A: It’s used for index actions to filter which records a user can access.

# In controller
      @posts = policy_scope(Post)
      
      # In policy
      class PostPolicy::Scope < Scope
        def resolve
          user.admin? ? scope.all : scope.where(published: true)
        end
      end

Q5: What does Pundit::NotAuthorizedError mean?

A: It means the user failed the policy check. You should rescue it.

rescue_from Pundit::NotAuthorizedError do
        flash[:alert] = "Access denied"
        redirect_to root_path
      end

Q6: Can you pass extra arguments into policies?

A: Yes, but it’s not built-in. Use custom methods or service objects instead of overloading the constructor.

Q7: How do you test a policy?

A: Test each permission method by creating user and resource instances and calling the policy method directly.

it "allows admin to destroy" do
        admin = User.new(role: "admin")
        post = Post.new
        expect(PostPolicy.new(admin, post).destroy?).to be true
      end

Q8: What does delegate mean in policies?

A: It’s used to forward calls to the user or model object to reduce repetition, e.g., delegate :admin?, to: :user.

Q9: Should you use one policy per model?

A: Yes. Each model should have its own policy class. This keeps permission logic isolated and clean.

Q10: What’s the difference between authorize and policy_scope?

A:

• authorize is for single records (e.g., show, update, delete)
• policy_scope is for lists (e.g., index views)

✅ Best Practices with Examples – Policy Pattern in Rails

1. Use One Policy Per Model

Each model (e.g., Post) should have its own policy (e.g., PostPolicy).

# app/policies/post_policy.rb
      class PostPolicy
        def update?
          user.admin? || user == post.author
        end
      end

2. Name Methods After Actions

Use the same names as your controller actions: show?, create?, update?, destroy?.

def destroy?
        user.admin?
      end

3. Always Use authorize in Controllers

This enforces security and prevents accidental exposure.

# PostsController
      def update
        @post = Post.find(params[:id])
        authorize @post
        @post.update(post_params)
      end

4. Use policy_scope in Index Actions

Limit data visibility to only what the user is allowed to see.

@posts = policy_scope(Post)

class PostPolicy::Scope < Scope
        def resolve
          user.admin? ? scope.all : scope.where(published: true)
        end
      end

5. Avoid Complex Conditionals

Split conditions into helper methods or use role-based delegation for clarity.

def update?
        admin_or_owner?
      end
      
      private
      
      def admin_or_owner?
        user.admin? || user == post.author
      end

6. Handle Unauthorized Access Globally

Rescue Pundit::NotAuthorizedError in your ApplicationController.

rescue_from Pundit::NotAuthorizedError, with: :user_not_authorized
      
      def user_not_authorized
        flash[:alert] = "Access denied."
        redirect_to(request.referer || root_path)
      end

7. Test Your Policies

Use RSpec or Minitest to test each policy method with different user roles.

it "allows admin to destroy posts" do
        user = User.new(role: "admin")
        post = Post.new
        expect(PostPolicy.new(user, post).destroy?).to be true
      end

8. Use ApplicationPolicy for Defaults

Define common methods like admin? once and inherit them in other policies.

# app/policies/application_policy.rb
      class ApplicationPolicy
        attr_reader :user, :record
      
        def admin?
          user.admin?
        end
      end

9. Authorize Nested Resources with Care

When dealing with nested routes, always authorize the right object (e.g., @comment not @post).

10. Don’t Authorize in Views

Use policy(@post).update? sparingly in views. Prefer to prepare authorization status in the controller.

🌍 Real-World Scenarios

• 🛡 A user can only edit their own blog posts.
• 🔒 Only admins can delete records.
• 👀 Users can only see projects they belong to.
• 💬 Comments can be edited by their authors but not others.
• 🧾 Invoices can only be viewed by the finance team or the customer who owns it.

🧠 Detailed Explanation

The Presenter Pattern is used in Rails to organize and simplify view-related logic that doesn’t belong in models or controllers.

Think of it like a **helper object** that “presents” your data the way your view needs it — combining, formatting, or enriching data from one or more models.

🎯 Why use it?

• ✅ Keep models focused on data and business logic
• ✅ Keep controllers clean from formatting code
• ✅ Make your views easier to read and maintain
• ✅ Combine multiple models if needed (e.g., User + Order)

📦 Example Use Case

You want to show a user’s full name, their join date (in words), and status badge in the UI.

Instead of cluttering the model or the view with that logic, you put it in a presenter:

# app/presenters/user_presenter.rb
      class UserPresenter
        def initialize(user, view)
          @user = user
          @view = view
        end
      
        def full_name
          "#{@user.first_name} #{@user.last_name}"
        end
      
        def joined_date
          @view.time_ago_in_words(@user.created_at) + " ago"
        end
      
        def status_label
          @user.active? ? "✅ Active" : "⛔ Inactive"
        end
      end

And then use it in your view like this:

@user_presenter = UserPresenter.new(@user, view_context)
      
      <p>Name: <%= @user_presenter.full_name %></p>
      <p>Joined: <%= @user_presenter.joined_date %></p>
      <p>Status: <%= @user_presenter.status_label %></p>

🧠 Think of it like:

• 🎨 A paintbrush that makes your raw data ready for display
• 📦 A wrapper that keeps logic out of your model and view
• 🔌 A clean plug between controller and view

Summary: The Presenter Pattern is all about making views smarter without making your models and controllers messy.

📘 Key Terms & Concepts – Presenter Pattern in Rails

🔁 Flow – How the Presenter Pattern Works

1. 💾 A model is fetched in the controller
   Example: @user = User.find(params[:id])
2. 🎁 A presenter is initialized with the model
   Example: @user_presenter = UserPresenter.new(@user, view_context)
3. 🧠 The presenter formats or combines data
   The presenter adds methods like full_name, joined_on, status_badge
4. 🖼 The view displays presenter methods
   Example: <%= @user_presenter.full_name %>

Controller ➝ Presenter ➝ View
        (model)       (format logic)   (output)

✅ This flow keeps formatting logic out of both the model and view.

📌 Where & How to Use Presenter Pattern

Use presenters anywhere you need to format, combine, or cleanly display model data in your views — especially when it starts cluttering your ERB or model files.

💡 Rule of Thumb: Use presenters when your view includes more than 2–3 conditionals, or when your model starts mixing display logic.

🧩 Gems & Libraries for Presenter Pattern in Rails

🛠️ Best Implementation – Pure Ruby Presenter in Rails

In this example, we’ll build a presenter to format and display user information like full name, join date, and status badge.

📁 Step 1: Create a Presenter Class

Path: app/presenters/user_presenter.rb

class UserPresenter
        def initialize(user, view_context)
          @user = user
          @view = view_context
        end
      
        def full_name
          "#{@user.first_name} #{@user.last_name}"
        end
      
        def joined_date
          @view.time_ago_in_words(@user.created_at) + " ago"
        end
      
        def status_badge
          if @user.active?
            @view.content_tag(:span, "Active", class: "badge badge-success")
          else
            @view.content_tag(:span, "Inactive", class: "badge badge-secondary")
          end
        end
      end

• ✅ Uses @view to access Rails helpers inside the presenter.
• ✅ Only includes view logic — no business rules.

🎮 Step 2: Use Presenter in the Controller

File: users_controller.rb

def show
        @user = User.find(params[:id])
        @user_presenter = UserPresenter.new(@user, view_context)
      end

🖼 Step 3: Call Presenter Methods in the View

File: views/users/show.html.erb

<h2><%= @user_presenter.full_name %></h2>
      <p>Joined: <%= @user_presenter.joined_date %></p>
      <p><%= @user_presenter.status_badge %></p>

✅ Your view is now clean, readable, and free from formatting logic.

🧪 Step 4: Test the Presenter

File: spec/presenters/user_presenter_spec.rb

require "rails_helper"
      
      describe UserPresenter do
        let(:user) { User.new(first_name: "Ali", last_name: "Khan", created_at: 2.days.ago, active: true) }
        let(:view) { ActionView::Base.new }
        let(:presenter) { UserPresenter.new(user, view) }
      
        it "returns full name" do
          expect(presenter.full_name).to eq("Ali Khan")
        end
      
        it "returns formatted join date" do
          expect(presenter.joined_date).to include("ago")
        end
      
        it "returns status badge" do
          expect(presenter.status_badge).to include("Active")
        end
      end

✅ Presenters are plain Ruby objects — easy to test!

📦 Bonus: Add Collection Presenter

To present lists of users cleanly:

class UserCollectionPresenter
        def initialize(users, view)
          @users = users
          @view = view
        end
      
        def each
          @users.map { |user| UserPresenter.new(user, @view) }
        end
      end

@user_list = UserCollectionPresenter.new(User.all, view_context)

<% @user_list.each.each do |presenter| %>
        <%= presenter.full_name %>
        <% end %>

💡 Example

Use case: Showing user full name, formatted date, and status in a dashboard.

# app/presenters/user_presenter.rb
  class UserPresenter
    def initialize(user, view)
      @user = user
      @view = view
    end
  
    def full_name
      "#{@user.first_name} #{@user.last_name}"
    end
  
    def joined_on
      @view.time_ago_in_words(@user.created_at) + " ago"
    end
  
    def status_tag
      @user.active? ? @view.content_tag(:span, "Active", class: "badge badge-success") :
                      @view.content_tag(:span, "Inactive", class: "badge badge-secondary")
    end
  end

# In controller
  @user_presenter = UserPresenter.new(@user, view_context)
  
  # In view
  <p><%= @user_presenter.full_name %></p>
  <p>Joined: <%= @user_presenter.joined_on %></p>
  <p><%= @user_presenter.status_tag %></p>

🔁 Alternative Methods

• Decorator Pattern: Similar, but wraps one model only.
• ViewComponent: Ideal for reusable visual components.
• Helpers: Fine for simple methods, not good for multiple model logic.

🛠️ Technical Questions & Answers – Presenter Pattern in Rails

Q1: What is the Presenter Pattern?

A: The Presenter Pattern is a design pattern that extracts view-specific logic from models and controllers into a separate object. This improves code readability, testability, and maintainability.

Q2: How is a presenter different from a helper?

A: Helpers are globally accessible and usually stateless. Presenters are **stateful** objects that are passed model(s) and view context, making them ideal for formatting and organizing complex view logic.

Q3: How do you create a presenter?

A: You create a plain Ruby class inside app/presenters/ and initialize it with a model and view_context.

class UserPresenter
        def initialize(user, view)
          @user = user
          @view = view
        end
      
        def full_name
          "#{@user.first_name} #{@user.last_name}"
        end
      end

Q4: Why do we pass view_context to presenters?

A: So the presenter can use Rails helpers like time_ago_in_words, number_to_currency, link_to, etc.

@user_presenter = UserPresenter.new(@user, view_context)

Q5: Can a presenter access multiple models?

A: Yes. Presenters can be initialized with multiple models or fetch them internally. This makes them ideal for views that need combined data.

class OrderPresenter
        def initialize(order, user, view)
          @order = order
          @user = user
          @view = view
        end
      end

Q6: Where should presenters live in a Rails project?

A: In app/presenters. You can auto-load this directory by adding it in config/application.rb if needed.

Q7: How do you test a presenter?

A: Presenters are plain Ruby objects. You can test them with RSpec or Minitest like any other PORO (Plain Old Ruby Object).

describe UserPresenter do
        it "returns full name" do
          user = User.new(first_name: "Ali", last_name: "Khan")
          view = ActionView::Base.new
          presenter = UserPresenter.new(user, view)
      
          expect(presenter.full_name).to eq("Ali Khan")
        end
      end

Q8: What problems does the presenter pattern solve?

A: It removes formatting and conditional logic from views and controllers, promotes reuse, makes views simpler, and keeps models focused on business logic.

Q9: What’s the difference between a presenter and a decorator?

A: A **decorator** wraps a single model and often adds behavior. A **presenter** can format one or more models and includes view helpers for presentation.

Q10: When should you not use a presenter?

A: When the logic is too simple (e.g., one-line method), a helper may suffice. Avoid presenters for business logic or service actions — they are only for presentation logic.

✅ Best Practices with Examples – Presenter Pattern in Rails

1. Name presenters after the resource

Use clear, singular names like UserPresenter, OrderPresenter, etc.

# Good
      class UserPresenter
      # Bad
      class UserFormatHelper

2. Store presenters in app/presenters/

This keeps structure consistent and allows easy autoloading.

# structure
      app/
      ├─ models/
      ├─ views/
      ├─ presenters/
      │   └─ user_presenter.rb

3. Use view_context to access Rails helpers

This allows presenters to use helpers like time_ago_in_words or link_to.

def joined_on
        @view.time_ago_in_words(@user.created_at) + " ago"
      end

4. Only include display logic — not business rules

Presenters should format data, not update or validate it.

# ✅ Good
      def full_name
        "#{@user.first_name} #{@user.last_name}"
      end
      
      # ❌ Bad
      def activate_account
        @user.update(active: true)  # should be in model or service

5. Use presenters in controllers, not views

Set the presenter in the controller so views stay clean.

# Controller
      @user_presenter = UserPresenter.new(@user, view_context)
      
      # View
      <%= @user_presenter.full_name %>

6. Keep presenters small and focused

Each presenter should do one job — don’t mix unrelated logic.

7. Combine multiple models only if needed

When you must present combined data (e.g., Order + User), pass both into the presenter.

class OrderPresenter
        def initialize(order, user, view)
          @order = order
          @user = user
          @view = view
        end
      end

8. Write unit tests for presenters

Test each method independently, just like any other Ruby object.

it "returns full name" do
        presenter = UserPresenter.new(user, view)
        expect(presenter.full_name).to eq("Ali Khan")
      end

9. Avoid database queries inside presenters

Fetch all required data in the controller and pass it to the presenter.

# ❌ Don't
      @user.orders.last  # querying inside presenter
      
      # ✅ Do
      @orders = @user.orders
      @presenter = UserPresenter.new(@user, @orders, view_context)

10. Reuse presenters in mailers and APIs (view rendering)

Presenters are plain Ruby objects — perfect for reuse across views, PDFs, emails, etc.

🌍 Real-World Scenarios

• 🧑‍💼 User dashboards with account and profile info
• 🛒 Order summary cards that include user, items, and shipping status
• 📊 Admin panels combining reports, metrics, and user activity
• 🎯 Marketing views combining content and statistics
• 📦 Invoicing pages showing customer, payment, and line item data

🧠 Detailed Explanation

The ViewComponent Pattern is a way to build small, reusable, and testable UI blocks in Rails using Ruby classes and templates.

Instead of writing lots of HTML in your views or repeating partials everywhere, you create a Component — a Ruby class that has its own template file.

🔍 Simple Definition

ViewComponent = Ruby class + HTML template = reusable UI block.

It helps you:

• ✅ Organize your views
• ✅ Reuse the same UI logic across pages
• ✅ Write tests for each UI piece

📦 Example Use Case

Let’s say you want to show a colored alert box (success, error, info) across your app.

Instead of repeating HTML or logic everywhere, you can create:

• A Ruby class: AlertComponent
• A template: alert_component.html.erb

Then use it anywhere with:

<%= render(AlertComponent.new(message: "Success!", type: :success)) %>

Result:

[Success!] ✅ You’ve saved your changes.

🤔 Why Use It?

• 🎯 Keeps logic and markup together
• 💡 Makes your views cleaner
• 🧪 Easy to test in isolation
• 🔁 Works well with Tailwind, Bootstrap, or any CSS

🧠 Think of it like:

• 🔌 A Lego piece you can plug into different pages
• 🧩 A self-contained widget with logic + display
• 📦 A mini partial that can be tested and reused

In short: ViewComponents give you the power of React/Vue-style components inside Rails using familiar Ruby + ERB.

📘 Key Terms & Concepts – ViewComponent Pattern

🔁 Flow – How ViewComponent Works

1. 1. You create a Component class
   Example: app/components/button_component.rb
   This file defines logic and accepts data (props).
2. 2. You create a template file
   Example: app/components/button_component.html.erb
   This file contains the actual HTML for the button.
3. 3. You render the component in a view
   Example: <%= render(ButtonComponent.new(text: "Save", type: :primary)) %>
4. 4. The component class processes the data
   It sets variables like @text and @type for use in the template.
5. 5. The template renders HTML
   Example: <button class="btn btn-{@type}">{@text}</button>

Result: Clean views, reusable logic, and testable HTML blocks.

📌 Where & How to Use ViewComponent in Rails

Use ViewComponents anywhere you repeat HTML + logic, or want reusable, testable UI.

💡 Tip: If you’re copying the same ERB partial more than twice, it’s a perfect case for a ViewComponent.

🧩 Gems & Libraries for ViewComponent Pattern

🛠️ Best Implementation – ViewComponent in Rails (Step-by-Step)

This example builds a reusable AlertComponent for displaying success/error/info messages across your app.

📦 Step 1: Install the Gem

# In Gemfile
      gem "view_component", require: "view_component/engine"

bundle install

This will auto-create support for app/components and ViewComponent testing.

📁 Step 2: Generate a Component

bin/rails generate component Alert message type

This creates:

• app/components/alert_component.rb
• app/components/alert_component.html.erb

🧠 Step 3: Add Logic to the Component

# app/components/alert_component.rb
      class AlertComponent < ViewComponent::Base
        def initialize(message:, type: :info)
          @message = message
          @type = type
        end
      end

🎨 Step 4: Create the Template

<!-- app/components/alert_component.html.erb -->
      <div class="alert alert-<%= @type %>">
        <%= @message %>
      </div>

This allows dynamic messages and alert types (e.g., success, error).

🖼️ Step 5: Render the Component in a View

<%= render(AlertComponent.new(message: "Saved successfully!", type: :success)) %>

✅ Use it anywhere you want consistent alert UI.

🧪 Step 6: Test the Component

File: spec/components/alert_component_spec.rb

require "rails_helper"
      
      RSpec.describe AlertComponent, type: :component do
        it "renders a success message" do
          render_inline(AlertComponent.new(message: "Saved!", type: :success))
      
          expect(page).to have_css(".alert-success", text: "Saved!")
        end
      end

👁️ Step 7: Add a Preview (Optional)

File: test/components/previews/alert_component_preview.rb

class AlertComponentPreview < ViewComponent::Preview
        def success
          render(AlertComponent.new(message: "Saved!", type: :success))
        end
      
        def error
          render(AlertComponent.new(message: "Something went wrong!", type: :danger))
        end
      end

✅ Visit /rails/view_components to preview all components (when preview is enabled).

🧩 Benefits of This Implementation

• ✅ Reusable: One component, multiple alert types
• ✅ Testable: Pure Ruby logic, clean template separation
• ✅ Encapsulated: No need for partials or global helper methods
• ✅ Design System Friendly: Works great with Tailwind or Bootstrap

💡 Example

app/components/alert_component.rb

class AlertComponent < ViewComponent::Base
    def initialize(message:, type: :info)
      @message = message
      @type = type
    end
  end

app/components/alert_component.html.erb

<div class="alert alert-<%= @type %>">
    <%= @message %>
  </div>

Usage in view:

<%= render(AlertComponent.new(message: "Saved!", type: :success)) %>

🔁 Alternative Concepts

• Partials: Reusable HTML snippets but lack testability and encapsulation.
• Helpers: Good for logic but not for rendering markup.
• Presenters: Help format data, but do not render full views like components.

🛠️ Technical Questions & Answers – ViewComponent

Q1: What is ViewComponent in Rails?

A: ViewComponent is a Ruby gem (by GitHub) that allows you to build reusable, testable UI components in Rails. Each component has a Ruby class and a corresponding HTML template.

# app/components/alert_component.rb
      class AlertComponent < ViewComponent::Base
        def initialize(message:, type: :info)
          @message = message
          @type = type
        end
      end

<!-- alert_component.html.erb -->
      <div class="alert alert-<%= @type %>">
        <%= @message %>
      </div>

Q2: How is ViewComponent different from partials?

A: Partials are templates only. ViewComponents have structure (Ruby class), logic, and tests.

Q3: How do you render a ViewComponent?

A: Use the render method in your views:

<%= render(AlertComponent.new(message: "Hello!", type: :info)) %>

Q4: Can you pass blocks (slots) to components?

A: Yes! You can pass nested content using slots:

# app/components/card_component.rb
      class CardComponent < ViewComponent::Base
        renders_one :header
        renders_one :body
      end

<%= render(CardComponent.new) do |c| %>
        <% c.header { "Card Title" } %>
        <% c.body { "This is the content." } %>
      <% end %>

Q5: How do you test a component?

A: Use render_inline in RSpec:

RSpec.describe AlertComponent, type: :component do
        it "renders a message" do
          render_inline(AlertComponent.new(message: "Test", type: :info))
          expect(page).to have_content("Test")
        end
      end

Q6: Can ViewComponents be previewed in development?

A: Yes! You can generate previews:

# test/components/previews/alert_component_preview.rb
      class AlertComponentPreview < ViewComponent::Preview
        def default
          render(AlertComponent.new(message: "Preview!", type: :info))
        end
      end

Then visit /rails/view_components to view them.

Q7: Can components render inside each other?

A: Yes. You can nest components:

<%= render(CardComponent.new) do |c| %>
        <% c.body do %>
          <%= render(ButtonComponent.new(text: "Click")) %>
        <% end %>
      <% end %>

Q8: What are the benefits of using ViewComponent?

• ✅ Testable, isolated components
• ✅ Reusable UI blocks
• ✅ Better structure and readability
• ✅ Cleaner separation of logic and markup

Q9: Can you use ViewComponent with Tailwind or Bootstrap?

A: Yes. Since ViewComponents render HTML, you can apply any CSS framework or utility class.

Q10: Should ViewComponents replace all partials?

A: Not always. Use ViewComponents when you need logic, reusability, or tests. Use partials for extremely simple templates.

✅ Best Practices with Examples – ViewComponent

1. ✅ Use clear naming with the `Component` suffix

Keep component classes obvious and consistent:

# Good
      class ButtonComponent < ViewComponent::Base
      # Bad
      class Btn < ViewComponent::Base

2. ✅ Keep logic in the Ruby class, not in the template

This makes your views cleaner and easier to test.

# app/components/alert_component.rb
      def status_class
        case @type
        when :success then "alert-success"
        when :error then "alert-danger"
        else "alert-info"
        end
      end

<!-- alert_component.html.erb -->
      <div class="alert <%= status_class %>"><%= @message %></div>

3. ✅ Use renders_one and renders_many for slots

This allows flexible and readable components:

renders_one :header
      renders_many :items

4. ✅ Write tests for every component

ViewComponents are meant to be testable — use render_inline in RSpec.

it "renders with message" do
        render_inline(AlertComponent.new(message: "Hi!", type: :success))
        expect(page).to have_content("Hi!")
      end

5. ✅ Use component previews in development

This helps you see components in isolation and test variations visually.

# test/components/previews/button_component_preview.rb
      class ButtonComponentPreview < ViewComponent::Preview
        def primary
          render(ButtonComponent.new(label: "Save", style: :primary))
        end
      end

6. ✅ Avoid using instance variables outside the component

All logic should be self-contained. Use arguments, not globals.

7. ✅ Use TailwindCSS or similar inside components

Keep styling declarative and scoped inside the template.

<button class="btn bg-blue-500 hover:bg-blue-600 text-white">
        <%= @label %>
      </button>

8. ✅ Organize components into folders if needed

Group them by domain, just like controllers or models.

app/components/
      ├── buttons/
      │   └── primary_button_component.rb
      ├── alerts/
      │   └── alert_component.rb

9. ✅ Reuse components inside other components

You can compose components for complex UI blocks:

<%= render(ButtonComponent.new(label: "Edit")) %>

10. ✅ Don’t over-componentize

Use ViewComponent for reusable or logic-heavy UIs. Use partials for one-time, static chunks.

🌍 Real-World Use Cases

• ⚠️ Alert boxes and notifications
• 🧩 Card components for dashboards
• 📦 Product listings in e-commerce views
• 📅 Calendars and schedule widgets
• 📄 PDF-renderable sections
• 🔁 Reusable form groups and inputs

🧠 Detailed Explanation

The Interactor Pattern is a way to organize one specific task (or action) in your Rails app into its own file, instead of putting that logic in controllers or models.

🎯 What is an Interactor?

An interactor is just a Ruby class that:

• 👔 Does one job (like “Create a user” or “Send an email”)
• 📦 Takes input (like form data)
• ✅ Returns success or failure
• 📤 Shares results with the controller or another interactor

📦 What does it look like?

# app/interactors/create_user.rb
      class CreateUser
        include Interactor
      
        def call
          user = User.new(context.params)
      
          if user.save
            UserMailer.welcome(user).deliver_later
            context.user = user
          else
            context.fail!(error: user.errors.full_messages.to_sentence)
          end
        end
      end

In your controller:

result = CreateUser.call(params: user_params)
      
      if result.success?
        redirect_to result.user
      else
        flash[:alert] = result.error
        render :new
      end

🤔 Why use it?

• ✅ Keeps controllers clean (no long methods)
• ✅ Keeps models focused on data, not process
• ✅ Makes business logic reusable and testable
• ✅ Makes complex actions easy to follow

🧠 Think of it like:

• 🧾 A to-do list handler: it takes an action and completes it step-by-step.
• 📤 A mailroom clerk: it gets something to do, runs it, and hands back the result.
• 🔌 A plugin: plug in any action like create user, place order, or notify admin.

In short: An interactor handles one action. It keeps your app tidy and your logic reusable.

📘 Key Terms & Concepts – Interactor Pattern

🔁 Flow – How the Interactor Pattern Works

1. 1. You create an interactor class
   Place it in app/interactors and define a call method.
2. 2. You include Interactor in the class
   This gives your class access to context and fail!.
3. 3. You pass input into call using a hash
   The input becomes part of the shared context.
4. 4. You execute business logic inside the call method
   If successful, you save results in context.
5. 5. You return the result and check success? or failure?
   This helps you handle success or error in the controller or another interactor.

# Step-by-step example:
      result = CreateOrder.call(user: current_user, params: order_params)
      
      if result.success?
        redirect_to result.order
      else
        render :new, alert: result.error
      end

📌 Where & How to Use Interactor Pattern in Rails

Use the Interactor Pattern anywhere you have multi-step business logic that shouldn’t live in controllers or models.

💡 Rule of Thumb: If a method has more than 2–3 responsibilities or conditionals, move it to an interactor.

🧩 Gems & Libraries – Interactor Pattern in Rails

🛠️ Best Implementation – Interactor Pattern in Rails

Let’s build a real-world example: CreateUser interactor that registers a user, sends a welcome email, and handles failure gracefully.

📦 Step 1: Install the interactor gem

# In your Gemfile
      gem 'interactor'

bundle install

📁 Step 2: Create the Interactor class

Generate and place interactors in app/interactors/.

# app/interactors/create_user.rb
      class CreateUser
        include Interactor
      
        def call
          user = User.new(context.params)
      
          if user.save
            UserMailer.welcome_email(user).deliver_later
            context.user = user
          else
            context.fail!(error: user.errors.full_messages.to_sentence)
          end
        end
      end

Highlights:

• 🎯 Uses context.params to access input
• 📩 Uses context.user to return output
• 🚫 Uses context.fail! for graceful failure

🖼️ Step 3: Use the Interactor in your controller

# app/controllers/users_controller.rb
      def create
        result = CreateUser.call(params: user_params)
      
        if result.success?
          redirect_to result.user, notice: "User created!"
        else
          flash[:alert] = result.error
          render :new
        end
      end

Why it’s better: The controller stays clean, and logic is easy to test separately.

🧪 Step 4: Test the Interactor

# spec/interactors/create_user_spec.rb
      require 'rails_helper'
      
      RSpec.describe CreateUser, type: :interactor do
        let(:valid_params) { { name: "Ali", email: "[email protected]", password: "123456" } }
        let(:invalid_params) { { name: "", email: "" } }
      
        it "creates a user with valid params" do
          result = CreateUser.call(params: valid_params)
      
          expect(result).to be_success
          expect(result.user).to be_persisted
        end
      
        it "fails with invalid params" do
          result = CreateUser.call(params: invalid_params)
      
          expect(result).to be_failure
          expect(result.error).to be_present
        end
      end

🔗 Step 5 (Optional): Use an Organizer to group steps

# app/interactors/register_user.rb
      class RegisterUser
        include Interactor::Organizer
      
        organize CreateUser, SendWelcomeGift, TrackSignupAnalytics
      end

💡 Each interactor in the chain shares the same context.

✅ Summary

• 🚀 Easy to read and test
• 🔁 Reusable in other workflows
• 🧹 Keeps controllers and models clean
• ❌ No more fat models or long controller methods

💡 Example

app/interactors/create_user.rb

class CreateUser
    include Interactor
  
    def call
      user = User.new(context.params)
      if user.save
        UserMailer.welcome(user).deliver_later
        context.user = user
      else
        context.fail!(error: user.errors.full_messages.to_sentence)
      end
    end
  end

Usage in controller:

result = CreateUser.call(params: user_params)
  
  if result.success?
    redirect_to result.user
  else
    flash[:alert] = result.error
    render :new
  end

🔁 Alternative Methods or Concepts

• Fat Models: Logic directly inside models (bad for readability).
• Command Objects: Similar to interactors but often lack context and fail! pattern.
• Service Objects: Manually built classes that perform a single operation.

🛠️ Technical Q&A – Interactor Pattern

Q1: What is the Interactor Pattern in Rails?

A: The Interactor Pattern encapsulates a single business action (e.g., create a user, charge a card) in a dedicated Ruby class. It keeps controllers and models clean and makes logic reusable and testable.

Q2: What gem is used to implement it?

A: The interactor gem by Collective Idea provides a DSL (`context`, `fail!`, `call`) for building interactors.

Q3: How do you define an interactor?

A: Create a class with `include Interactor`, then define the `call` method.

class CreateUser
        include Interactor
      
        def call
          user = User.new(context.params)
          context.user = user if user.save
          context.fail!(error: "Invalid user") unless user.persisted?
        end
      end

Q4: What is context in an interactor?

A: It’s a shared object used to receive inputs and return results.

• context.params → input
• context.user → output
• context.success? / context.failure? → status check

Q5: What does context.fail! do?

A: It stops the interactor and marks the result as a failure. Execution after it is skipped.

context.fail!(error: "Email missing") if context.params[:email].blank?

Q6: How do you use an interactor in a controller?

A:

result = CreateUser.call(params: user_params)
      
      if result.success?
        redirect_to result.user
      else
        render :new, alert: result.error
      end

Q7: How do you test an interactor?

A: You call the interactor and assert on the result’s success/failure and output values.

RSpec.describe CreateUser do
        it "creates a user" do
          result = described_class.call(params: { name: "Ali" })
          expect(result).to be_success
          expect(result.user).to be_persisted
        end
      end

Q8: What is an Organizer in the interactor gem?

A: An Organizer is a way to group multiple interactors into one workflow. They all share the same context.

class SignupFlow
        include Interactor::Organizer
      
        organize CreateUser, SendWelcomeEmail, LogAnalytics
      end

Q9: Can you pass multiple values into an interactor?

A: Yes. You pass them as a hash to call. They’re accessible via context.

CreateUser.call(params: user_params, current_user: admin_user)

Q10: When should you use an interactor vs a service object?

A: Use an interactor when you want structured failure handling, shared context, and reusable workflow composition. Use a service object for simple one-liners or low logic tasks.

✅ Best Practices with Examples – Interactor Pattern

1. ✅ Name your interactor after the action it performs

Use clear, verb-based names like CreateUser, SendInvoice, or CancelOrder.

# Good
      class CreateUser
      # Bad
      class UserService

2. ✅ Keep logic inside call only

All interactor logic must be placed inside the call method. Avoid defining unrelated methods unless you extract private helpers.

def call
        context.user = User.create(context.params)
      end

3. ✅ Use context to pass and return data

Use context like a structured input/output hash:

def call
        context.user = User.new(context.params)
      end

4. ✅ Use context.fail! to exit early on error

Fail fast and avoid nested if conditions.

def call
        context.fail!(error: "Email missing") if context.params[:email].blank?
      end

5. ✅ Keep each interactor focused on a single task

Each interactor should do one job — not a mix of DB write, email, and analytics.

# ✅ CreateUser
      # ✅ SendWelcomeEmail
      # ✅ TrackSignup

6. ✅ Chain complex workflows using Interactor::Organizer

This keeps each interactor simple while allowing step-by-step orchestration.

class SignupFlow
        include Interactor::Organizer
      
        organize CreateUser, SendWelcomeEmail, TrackSignupAnalytics
      end

7. ✅ Use context.success? and context.failure? in consumers

Don’t rely on return values — always check status.

result = CreateUser.call(params: user_params)
      
      if result.success?
        redirect_to result.user
      else
        flash[:alert] = result.error
      end

8. ✅ Write unit tests for every interactor

Interactor logic is isolated and easy to test:

it "fails when email is blank" do
        result = CreateUser.call(params: { email: "" })
        expect(result).to be_failure
      end

9. ✅ Keep side effects (emails, jobs) isolated

For example, send email in a separate SendWelcomeEmail interactor, not inside CreateUser.

10. ✅ Keep interactors in app/interactors

Maintain consistent structure to organize them clearly:

app/
      ├─ interactors/
      │  ├─ create_user.rb
      │  ├─ send_welcome_email.rb
      │  └─ register_user.rb

🌍 Real-World Scenarios

• 👤 User sign-up with onboarding steps
• 📦 Order processing and payment handling
• 📧 Sending notifications after events
• 🔁 Importing/exporting data pipelines
• 📊 Background jobs with business logic

🧠 Detailed Explanation

The Repository Pattern is a way to organize your code so that all the database queries and logic for a model are stored in one place — called a “repository.”

This helps you:

• ✅ Keep your controllers and services clean
• ✅ Avoid repeating queries everywhere
• ✅ Easily swap or change how data is fetched later
• ✅ Test your business logic without touching the database

📦 Simple Example

Before (bad): You put queries in the controller

# In controller
      @users = User.where(active: true).order(:created_at)

After (good): You move that logic to a repository

# app/repositories/user_repository.rb
      class UserRepository
        def self.active_users
          User.where(active: true).order(:created_at)
        end
      end

# In controller
      @users = UserRepository.active_users

🎯 What goes inside a Repository?

• 📥 Query logic (e.g., filters, finders)
• 📤 Data manipulation (e.g., create, update, delete)
• 🔎 Aggregations or custom searches

🧠 Think of it like:

• 📚 A library for all data-related tasks for one model
• 🔌 A plug-in between your app and the database
• 🧹 A way to keep your code clean, dry, and organized

In short: The Repository Pattern gives you one central place to handle all data access for a model, so your app stays clean and easy to manage.

📘 Key Terms & Concepts – Repository Pattern

🔁 Flow – How the Repository Pattern Works

1. 1. Create a Repository Class
   Place it in app/repositories/, e.g., UserRepository.
2. 2. Add query methods inside the class
   Use class methods to define operations like find_by_email or active_users.
3. 3. Replace raw queries in controllers/services
   Instead of writing queries directly in your app code, call the repository method.
4. 4. Use repository methods across the app
   Call them from controllers, services, jobs, mailers, etc.
5. 5. Refactor and test easily
   Update or test logic in one place without touching multiple files.

Example:

# app/repositories/user_repository.rb
      class UserRepository
        def self.recent(limit = 10)
          User.order(created_at: :desc).limit(limit)
        end
      end

# app/controllers/dashboard_controller.rb
      @users = UserRepository.recent(5)

📌 Where & How to Use the Repository Pattern in Rails

The Repository Pattern is perfect for organizing and reusing query logic across your Rails app.

✅ Tip: If you’re copying or repeating a query more than twice — it’s a sign you should move it into a repository method.

🧩 Gems & Libraries – Repository Pattern in Rails

🛠️ Best Implementation – Repository Pattern in Rails (Step-by-Step)

Let’s build a repository for the User model. It will handle common queries like fetching active users, finding by email, and paginating users.

📁 Step 1: Create the Repository Directory

Create a folder in your app to keep repositories organized:

# Terminal
      mkdir app/repositories

📦 Step 2: Create the Repository Class

# app/repositories/user_repository.rb
      class UserRepository
        def self.all
          User.all
        end
      
        def self.find_by_email(email)
          User.find_by(email: email)
        end
      
        def self.active_users
          User.where(active: true).order(created_at: :desc)
        end
      
        def self.paginated(page:, per_page:)
          User.order(created_at: :desc).page(page).per(per_page)
        end
      
        def self.created_after(date)
          User.where("created_at > ?", date)
        end
      end

🧠 Each method is clean, focused, and reusable.

🧪 Step 3: Use the Repository in Your Controller

# app/controllers/users_controller.rb
      def index
        @users = UserRepository.paginated(page: params[:page], per_page: 20)
      end
      
      def show
        @user = UserRepository.find_by_email(params[:email])
      end

✅ Keeps the controller lean and readable.

🧪 Step 4: Add RSpec Test for the Repository

# spec/repositories/user_repository_spec.rb
      require 'rails_helper'
      
      RSpec.describe UserRepository do
        let!(:user1) { create(:user, email: "[email protected]", active: true) }
        let!(:user2) { create(:user, email: "[email protected]", active: false) }
      
        it "finds user by email" do
          result = described_class.find_by_email("[email protected]")
          expect(result).to eq(user1)
        end
      
        it "returns only active users" do
          results = described_class.active_users
          expect(results).to include(user1)
          expect(results).not_to include(user2)
        end
      end

🎯 Easy to test each query in isolation.

📘 Step 5: Follow Naming & Structure Conventions

• UserRepository → Handles all User queries
• Use self.method for reusability
• Avoid adding business logic — only query & fetch logic
• Keep method names expressive like active_users, created_after

🔗 Bonus: Inject Repositories in Services

# app/services/report_service.rb
      class ReportService
        def initialize(user_repo = UserRepository)
          @user_repo = user_repo
        end
      
        def recent_signups
          @user_repo.created_after(7.days.ago)
        end
      end

💡 This makes the service testable and decoupled from ActiveRecord.

✅ Summary

• 🏗 Keep all queries for one model in its own repository
• 🧹 Makes controllers, services, and jobs cleaner
• 🔁 Encourages reuse and testability
• 🧪 Easy to test without touching controllers or the DB layer directly

💡 Example

app/repositories/user_repository.rb

class UserRepository
    def self.active_users
      User.where(active: true)
    end
  
    def self.find_by_email(email)
      User.find_by(email: email)
    end
  
    def self.create_user(attrs)
      User.create(attrs)
    end
  end

Usage:

users = UserRepository.active_users
  admin = UserRepository.find_by_email("[email protected]")

🔁 Alternative Patterns

• Service Objects: Good for actions, but not for encapsulating query logic.
• Query Objects: Ideal for complex searches and filters.
• Concerns/Scopes: Keep logic in models but can lead to bloated files.

🛠️ Technical Q&A – Repository Pattern in Rails

Q1: What is the Repository Pattern?

A: The Repository Pattern separates the database query logic from the rest of your application. It provides a clean API for accessing data while hiding the details of the ORM (e.g., ActiveRecord).

Q2: Why should I use a repository instead of putting queries in controllers?

A: Repositories help you avoid repetition, keep controllers lean, isolate data access for testing, and improve maintainability.

# Controller with repo:
      @users = UserRepository.active_users

Q3: What should be inside a repository class?

A: Only query-related logic: finding, filtering, sorting, and fetching records.

class ProductRepository
        def self.latest(limit = 5)
          Product.order(created_at: :desc).limit(limit)
        end
      end

Q4: Can repositories return ActiveRecord objects?

A: Yes. In standard Rails, repositories usually return ActiveRecord objects or collections.

user = UserRepository.find_by_email("[email protected]")

Q5: How do you write tests for repositories?

A: Use RSpec or Minitest to test inputs and expected output from repository methods.

RSpec.describe UserRepository do
        it "returns only active users" do
          create(:user, active: true)
          create(:user, active: false)
          expect(UserRepository.active_users.count).to eq(1)
        end
      end

Q6: How does a repository improve testability?

A: You can mock/stub repository methods in services or controllers instead of relying on real DB records, making tests faster and more isolated.

allow(UserRepository).to receive(:find_by_email).and_return(mock_user)

Q7: How does a repository differ from a service object?

A: A repository handles **data access**, while a service object performs **business logic or actions**.

# Repository
      OrderRepository.pending_today
      
      # Service
      OrderProcessor.new(order).process

Q8: Where do I store repository classes?

A: Place them in app/repositories. You can namespace them if needed (e.g., Admin::UserRepository).

Q9: Can a repository access multiple models?

A: Yes, but only if it’s for cross-related query logic. For example, a ReportRepository might pull data from User, Order, and Product.

Q10: Is the Repository Pattern required in Rails?

A: No, it’s optional. Rails encourages “fat models, skinny controllers”, but using repositories adds better structure to medium and large apps.

✅ Best Practices with Examples – Repository Pattern in Rails

1. ✅ Keep one repository per model

Each repository should be responsible for a single model (e.g., UserRepository for User).

# Good
      class UserRepository
        def self.active
          User.where(active: true)
        end
      end

2. ✅ Avoid business logic in repositories

Repositories are only for data access. Put business rules in service objects.

# 🚫 Don't
      UserRepository.promote_user_to_admin(user)
      
      # ✅ Do
      UserPromoter.new(user).call

3. ✅ Keep repository methods short and descriptive

Name methods clearly based on what they return.

def self.registered_last_7_days
        User.where("created_at > ?", 7.days.ago)
      end

4. ✅ Use repositories in controllers, services, jobs

This removes the need for repeated queries across the app.

# Instead of repeating:
      User.where(active: true)
      
      # Use:
      UserRepository.active

5. ✅ Support flexible inputs using keyword args

Make methods reusable and clear to call.

def self.paginated(page:, per:)
        User.order(:created_at).page(page).per(per)
      end

6. ✅ Return ActiveRecord relations when chaining is useful

This allows callers to further filter if needed.

def self.active
        User.where(active: true)
      end
      
      # Controller
      UserRepository.active.limit(10)

7. ✅ Keep repositories testable and isolated

Test them directly with RSpec and use factories for input.

RSpec.describe UserRepository do
        it "finds user by email" do
          user = create(:user, email: "[email protected]")
          result = UserRepository.find_by_email("[email protected]")
          expect(result).to eq(user)
        end
      end

8. ✅ Namespace repositories for subdomains if needed

For large apps, use namespaced repositories for separation.

Admin::UserRepository.recent

9. ✅ Use dependency injection in services

This makes services more flexible and testable.

class ReportService
        def initialize(user_repo = UserRepository)
          @user_repo = user_repo
        end
      end

10. ✅ Document expected input/output for complex methods

Especially if your method takes multiple filters or conditions.

# Returns users created within a given time range
      def self.created_between(start_date, end_date)
        User.where(created_at: start_date..end_date)
      end

🌍 Real-World Use Cases

• 👥 Managing user filters and paginated queries
• 📦 Inventory queries in warehouse management
• 📊 Complex report generation logic
• 🔗 Aggregating data from multiple models for APIs
• 🔍 Multi-condition search and export modules

🧠 Detailed Explanation

The Command Pattern is a way to wrap a specific action — like “create a user” or “send an email” — inside its own Ruby class. This pattern turns that action into a command object that can be reused, tested, and passed around your app.

🎯 What does it mean in Rails?

In Rails, you might have logic in your controller like this:

# Not clean — logic inside controller
      def create
        user = User.new(params[:user])
        if user.save
          UserMailer.welcome(user).deliver_later
          redirect_to user
        else
          render :new
        end
      end

With the Command Pattern, you move all of that logic into a plain Ruby class:

# app/commands/create_user_command.rb
      class CreateUserCommand
        def initialize(params)
          @params = params
        end
      
        def call
          user = User.new(@params)
          if user.save
            UserMailer.welcome(user).deliver_later
            user
          else
            raise StandardError, user.errors.full_messages.to_sentence
          end
        end
      end

Now the controller is clean:

def create
        @user = CreateUserCommand.new(user_params).call
        redirect_to @user
      rescue StandardError => e
        flash[:alert] = e.message
        render :new
      end

🤔 Why use it?

• ✅ Keeps your controllers clean
• ✅ Makes actions reusable across jobs, services, or CLI tasks
• ✅ Easier to test because logic is isolated
• ✅ Supports undo/redo or queuing logic (like background jobs)

🧠 Think of it like:

A command object is like a task card:

• ✍️ You write down the task (e.g., “create user”)
• 📦 Pass it to someone (controller, job, etc.)
• ✅ They run the task using one consistent method: call

In short: The Command Pattern lets you package logic into a single, clean, reusable object with one job.

📘 Key Terms & Concepts – Command Pattern

🔁 Flow – How the Command Pattern Works in Rails

1. 1. Create a Command Class
   A plain Ruby class placed in app/commands/ (e.g., CreateUserCommand).
2. 2. Define an initialize method
   It receives the inputs your command needs (e.g., user params).
3. 3. Define the call method
   This contains the logic to execute the command.
4. 4. Use the command in controllers, jobs, or services
   Instead of inline logic, simply call .new(...).call.
5. 5. Return result or raise error
   Commands usually return an object or raise if something goes wrong.

🔧 Example:

# app/commands/create_user_command.rb
      class CreateUserCommand
        def initialize(params)
          @params = params
        end
      
        def call
          user = User.new(@params)
          raise StandardError, "Invalid user" unless user.save
      
          UserMailer.welcome(user).deliver_later
          user
        end
      end

Usage:

# In controller
      @user = CreateUserCommand.new(user_params).call

📌 Where & How to Use the Command Pattern in Rails

Use the Command Pattern for any action that:

• ✅ Involves multiple steps (e.g., saving + emailing)
• ✅ May be reused in different places (e.g., controller + background job)
• ✅ Requires clean separation of concerns

✅ Tip: Use the Command Pattern when your controller method feels too long or is doing more than one thing.

🧩 Gems & Libraries – Command Pattern in Rails

🛠️ Best Implementation – Command Pattern in Rails (Step-by-Step)

Let’s walk through a complete example: CreateUserCommand — a command object that creates a user and sends a welcome email.

📁 Step 1: Create Command Directory

Place your command objects in a dedicated folder:

# Terminal
      mkdir app/commands

📦 Step 2: Build the Command Class

Each command has:

• Constructor: receives dependencies/params
• call method: executes the action

# app/commands/create_user_command.rb
      class CreateUserCommand
        def initialize(params)
          @params = params
        end
      
        def call
          user = User.new(@params)
      
          if user.save
            UserMailer.welcome_email(user).deliver_later
            return user
          else
            raise StandardError, user.errors.full_messages.to_sentence
          end
        end
      end

🧼 Step 3: Use it in the Controller

# app/controllers/users_controller.rb
      def create
        @user = CreateUserCommand.new(user_params).call
        redirect_to @user, notice: "User created!"
      rescue StandardError => e
        flash[:alert] = e.message
        render :new
      end

🎯 Now your controller is short and readable!

🧪 Step 4: Add RSpec Tests

# spec/commands/create_user_command_spec.rb
      require 'rails_helper'
      
      RSpec.describe CreateUserCommand do
        let(:valid_params)   { { name: "Ali", email: "[email protected]", password: "123456" } }
        let(:invalid_params) { { name: "", email: "invalid" } }
      
        it "creates a user successfully" do
          user = described_class.new(valid_params).call
          expect(user).to be_persisted
        end
      
        it "raises error with invalid data" do
          expect {
            described_class.new(invalid_params).call
          }.to raise_error(StandardError, /Email/)
        end
      end

🧪 Optional: Use with Sidekiq for Background Execution

# app/jobs/create_user_job.rb
      class CreateUserJob < ApplicationJob
        queue_as :default
      
        def perform(params)
          CreateUserCommand.new(params).call
        end
      end

# Usage
      CreateUserJob.perform_later(params)

📘 Naming & Structure Guidelines

• ✅ Name command like an action (e.g., CreateUserCommand, SendInvoiceCommand)
• ✅ Store in app/commands
• ✅ Keep the call method short and focused
• ✅ Raise errors instead of silently failing
• ✅ Reuse commands in services, jobs, or CLI

✅ Summary

• 🚀 Isolates logic into testable units
• ♻️ Reusable across controllers, jobs, services
• 🧹 Keeps your MVC clean and modular
• 🧪 Simple to test using RSpec

💡 Example

app/commands/create_user_command.rb

class CreateUserCommand
    def initialize(params)
      @params = params
    end
  
    def call
      user = User.new(@params)
      if user.save
        UserMailer.welcome(user).deliver_later
        user
      else
        raise StandardError, user.errors.full_messages.to_sentence
      end
    end
  end

Usage:

user = CreateUserCommand.new(user_params).call

🔁 Alternative Concepts

• Interactor Pattern: Similar, but uses context and fail! for structured results.
• Service Objects: Can serve as simple command-style logic but without formal structure.
• ActiveJob: For background jobs that also represent commands.

🛠️ Technical Q&A – Command Pattern in Rails

Q1: What is the Command Pattern in Rails?

A: The Command Pattern wraps a specific business action in a single class (e.g., CreateUserCommand), allowing it to be reused, tested, queued, or replaced easily.

Q2: What does a command class look like?

A: It usually contains an initialize method to receive data and a call method to run the action.

class CreateUserCommand
        def initialize(params)
          @params = params
        end
      
        def call
          user = User.new(@params)
          raise "Invalid user" unless user.save
          user
        end
      end

Q3: How is it different from a service object?

A: A command is a type of service object, but it always follows a pattern:

• One action
• Callable via .call
• Focused and isolated

Q4: Where should command classes be stored?

A: Inside app/commands. You can namespace them by feature (e.g., Admin::SendReportCommand).

Q5: How do you use a command in a controller?

# In controller
      @user = CreateUserCommand.new(user_params).call

Q6: Can a command return values?

A: Yes. It can return the result of the operation (e.g., a user object) or raise an error on failure.

Q7: Can commands be reused in jobs or services?

A: Absolutely. That’s one of their strengths. Example:

class CreateUserJob < ApplicationJob
        def perform(params)
          CreateUserCommand.new(params).call
        end
      end

Q8: How do you test a command object?

A: Call the command with test data and check for expected results.

it "creates a user" do
        user = CreateUserCommand.new(valid_params).call
        expect(user).to be_persisted
      end

Q9: What if the command fails?

A: Commands usually raise an exception or return a result object (like with dry-monads).

Q10: Should commands be idempotent?

A: Yes, ideally. Running the same command twice shouldn't cause data corruption or duplication.

✅ Best Practices with Examples – Command Pattern in Rails

1. ✅ Use one class per action

Keep your command focused on one task. Don’t combine user creation and analytics tracking in the same class.

# Good
      class CreateUserCommand; def call; ...; end; end
      
      # Bad
      class UserCommand; def create_and_notify_and_log; ...; end; end

2. ✅ Use a call method as the entry point

This makes the command easier to understand and consistent across your codebase.

def call
        # perform the action here
      end

3. ✅ Raise exceptions on failure or use dry-monads for control

This allows you to handle errors explicitly and keeps the behavior predictable.

raise StandardError, "Invalid user" unless user.save

4. ✅ Store all command classes in app/commands

Keep them organized for easy discovery and maintenance.

app/
      └── commands/
          └── create_user_command.rb

5. ✅ Keep your commands dependency-free (no Rails-specific methods)

This makes them easier to test, reuse in jobs, rake tasks, or even CLI scripts.

6. ✅ Inject dependencies (params or services) via initialize

Use constructor arguments to pass data or service objects into the command.

def initialize(params, notifier: UserMailer)
        @params = params
        @notifier = notifier
      end

7. ✅ Return meaningful data (not just true/false)

Return the created object, or a result object, so the caller can act on it.

user = CreateUserCommand.new(params).call
      redirect_to user

8. ✅ Add matching test specs

Test for both success and failure scenarios with real inputs.

expect {
        CreateUserCommand.new(invalid_params).call
      }.to raise_error(StandardError)

9. ✅ Use commands in controllers, jobs, services, and rake tasks

Don’t repeat logic across your app. Centralize in commands.

# Controller
      CreateUserCommand.new(params).call
      
      # Job
      SendInvoiceCommand.new(invoice_id).call

10. ✅ Name commands clearly and consistently

Use verbs: CreateUserCommand, SendReportCommand, CancelOrderCommand.

🌍 Real-World Use Cases

• ✅ Creating a user and sending welcome email
• 📦 Processing an e-commerce order
• 📧 Sending bulk marketing emails
• 📊 Exporting a report
• 🔁 Cancelling a subscription

🧠 Detailed Explanation – Domain-Driven Design (DDD)

Domain-Driven Design (DDD) is an approach to software development that focuses on the real-world business logic behind your application. Instead of organizing your code by type (controllers, models, etc.), DDD encourages you to organize it by business area or domain.

🧠 Why use DDD in Rails?

Rails apps often become messy as they grow because everything goes into models or controllers. DDD helps by splitting logic into **domains** (e.g., Orders, Payments, Users) and grouping related behavior together.

🎯 Core idea:

• 👥 Work with your business team to understand their language and processes
• 🧠 Model that understanding in code
• 📦 Organize your app by “bounded contexts” instead of types (like models/controllers)

📦 Example:

Let’s say your app has payments and inventory. Instead of stuffing everything into models:

# ❌ Bad – everything in one fat model
      class Order < ApplicationRecord
        def send_invoice
          # invoice logic
        end
        def update_stock
          # inventory logic
        end
      end

Use DDD to split it:

# ✅ Better
      # app/domains/billing/invoice_generator.rb
      module Billing
        class InvoiceGenerator
          def initialize(order); @order = order; end
          def generate; ... end
        end
      end
      
      # app/domains/inventory/stock_updater.rb
      module Inventory
        class StockUpdater
          def initialize(order); @order = order; end
          def update; ... end
        end
      end

🗂 Folder Structure Example:

app/
      ├── domains/
      │   ├── billing/
      │   │   └── invoice_generator.rb
      │   ├── inventory/
      │   │   └── stock_updater.rb
      │   └── users/
      │       └── register_user.rb

🧠 Think of it like:

Instead of organizing by MVC (model, view, controller), you organize by how your business works:

• 📦 Bounded Context = A self-contained area (e.g., Inventory)
• 🎯 Command = One task (e.g., RegisterUser)
• 🔄 Aggregate = A business object and its related data/actions

Bottom line: DDD helps your Rails app grow in a clean, maintainable, and business-aligned way.

📘 Key Terms & Concepts – Domain-Driven Design (DDD)

🔁 Flow – How to Use Domain-Driven Design in Rails

1. 1. Understand the Business Domain
   Work closely with domain experts (e.g., product owners, clients) to understand how their world works. Write down their terminology.
2. 2. Define Bounded Contexts
   Break your system into clear, separate business areas — e.g., Payments, Inventory, Users.
3. 3. Create Folders by Domain, Not Type
   Inside app/domains, create folders for each bounded context:

   app/domains/
         ├── billing/
         ├── inventory/
         ├── users/

4. 4. Move Business Logic to Domain Classes
   Use plain Ruby objects to handle logic like:
   • Billing::InvoiceGenerator
   • Inventory::StockAdjuster
5. 5. Use Commands for Actions
   For each task, create a command object like CreateOrderCommand or ShipItemCommand. These live inside the domain and execute logic.
6. 6. Keep Domain Objects Framework-Free
   Don’t include ActiveRecord, helpers, or Rails concerns. These are pure business logic.
7. 7. Coordinate with Application Services
   In Rails controllers, call application services or command objects to execute domain logic.

Example:

# Controller
      def create
        @invoice = Billing::CreateInvoiceCommand.new(order_id: params[:id]).call
        redirect_to @invoice
      end

📌 Where & How to Use DDD in Rails

✅ Rule of Thumb: Use DDD when your business logic is growing and starting to feel messy in controllers or models.

🧩 Gems & Libraries – Domain-Driven Design (DDD) in Rails

🛠️ Best Implementation – Domain-Driven Design in Rails

This example shows how to implement DDD in a real-world Rails application for a Billing domain, which includes generating invoices and sending payment emails.

📁 Step 1: Create the Domain Folder Structure

Group domain logic by context under app/domains/.

app/
      ├── domains/
      │   ├── billing/
      │   │   ├── create_invoice_command.rb
      │   │   ├── invoice.rb
      │   │   └── mailers/
      │   │       └── invoice_mailer.rb
      │   └── inventory/
      │       └── stock_adjuster.rb

📦 Step 2: Create a Value Object (optional but recommended)

Use `dry-struct` for immutable, typed data objects.

# app/domains/billing/value_objects/money.rb
      module Billing
        module ValueObjects
          class Money < Dry::Struct
            attribute :amount, Types::Coercible::Float
            attribute :currency, Types::Strict::String
          end
        end
      end

⚙️ Step 3: Write a Domain Command (Business Action)

# app/domains/billing/create_invoice_command.rb
      module Billing
        class CreateInvoiceCommand
          def initialize(order)
            @order = order
          end
      
          def call
            total = @order.line_items.sum(&:price)
            invoice = Invoice.create!(order_id: @order.id, total: total)
            InvoiceMailer.with(invoice: invoice).deliver_later
            invoice
          end
        end
      end

📨 Step 4: Domain Mailer (Optional Email Layer)

# app/domains/billing/mailers/invoice_mailer.rb
      module Billing
        class InvoiceMailer < ApplicationMailer
          def with(invoice:)
            @invoice = invoice
            mail(to: @invoice.customer_email, subject: "Your Invoice")
          end
        end
      end

🧼 Step 5: Use Command in Controller or Service

# app/controllers/orders_controller.rb
      def create_invoice
        invoice = Billing::CreateInvoiceCommand.new(@order).call
        redirect_to invoice_path(invoice), notice: "Invoice created"
      rescue => e
        redirect_to @order, alert: e.message
      end

🧪 Step 6: Add a Unit Test

# spec/domains/billing/create_invoice_command_spec.rb
      require 'rails_helper'
      
      RSpec.describe Billing::CreateInvoiceCommand do
        let(:order) { create(:order_with_items) }
      
        it "creates an invoice and sends email" do
          expect {
            Billing::CreateInvoiceCommand.new(order).call
          }.to change(Invoice, :count).by(1)
            .and change { ActionMailer::Base.deliveries.count }.by(1)
        end
      end

📌 Bonus: Use `zeitwerk` for Autoloading

Rails 6+ autoloads namespaced modules like Billing::CreateInvoiceCommand by default — no need to require manually.

✅ Summary

• Group logic by domain (not by Rails type)
• Use commands to encapsulate actions
• Use value objects for clean, reusable data types
• Keep domain logic free of controller/model clutter
• Make everything testable in isolation

💡 Examples

app/domains/billing/invoice_aggregator.rb

module Billing
    class InvoiceAggregator
      def initialize(order)
        @order = order
      end
  
      def generate
        # Invoice logic across order items
      end
    end
  end

Controller:

Billing::InvoiceAggregator.new(order).generate

🔁 Alternative Concepts

• Service Layer: Central place for domain logic without domain-based boundaries
• Modular Monolith: Uses DDD-like separation without microservices
• Active Record pattern: Traditional Rails approach—great for CRUD but limited for complexity

🛠️ Technical Q&A – Domain-Driven Design (DDD) in Rails

Q1: What is Domain-Driven Design?

A: DDD is a software design approach that structures code based on the business domain. Instead of organizing by MVC types (models/controllers), DDD uses bounded contexts, entities, value objects, and aggregates to reflect real-world behavior and rules in code.

Q2: What is a Bounded Context in DDD?

A: A bounded context defines a logical boundary within the application where a specific domain model applies. Each context has its own language, rules, and logic. In Rails, you can implement this with modules and folders like app/domains/billing.

Q3: How is an Entity different from a Value Object?

A: An Entity has a unique identifier (like a User or Order) and can change over time. A Value Object (like Money or Address) has no identity and is immutable — it's defined only by its values.

# Value Object using dry-struct
      module Billing
        class Money < Dry::Struct
          attribute :amount, Types::Coercible::Float
          attribute :currency, Types::String
        end
      end

Q4: What is an Aggregate?

A: An aggregate is a cluster of domain objects (entities + value objects) treated as a single unit. The root (aggregate root) controls access to its parts.

# Example: Order as aggregate root
      class Order < ApplicationRecord
        has_many :order_items
      
        def add_item(product, quantity)
          order_items.build(product: product, quantity: quantity)
        end
      end

Q5: How do you structure DDD folders in Rails?

A: Under app/domains, create folders for each context:

app/domains/
      ├── billing/
      │   ├── create_invoice_command.rb
      │   ├── value_objects/
      │   └── invoice_mailer.rb
      ├── users/
      └── inventory/

Q6: How do you keep domain logic out of controllers?

A: Use command objects or application services inside your domain folder:

# Controller
      def create
        Billing::CreateInvoiceCommand.new(order).call
      end

Q7: How do you test domain logic in DDD?

A: Write unit tests for each command or service, mocking only external boundaries.

RSpec.describe Billing::CreateInvoiceCommand do
        it "creates an invoice and sends mail" do
          expect {
            described_class.new(order).call
          }.to change(Invoice, :count).by(1)
        end
      end

Q8: What is Ubiquitous Language?

A: A shared vocabulary between developers and domain experts. This language is used in both code and conversations to avoid misunderstandings.

Q9: What is the role of Application Services?

A: Application services coordinate domain objects to fulfill use cases. They do not contain business logic themselves.

Q10: When should you apply DDD in a Rails app?

A: DDD is helpful when:

• Business logic is complex or growing fast
• Multiple teams or subdomains are involved
• Your app needs long-term maintainability

✅ Best Practices with Examples – Domain-Driven Design in Rails

1. ✅ Organize by Domain, Not by Type

Instead of placing all models or services in one folder, group by business context.

# Good
      app/domains/billing/invoice_generator.rb
      
      # Bad
      app/models/invoice.rb
      app/services/generate_invoice.rb

2. ✅ Keep Domain Logic Framework-Free

Domain classes should not depend on Rails features like ActiveRecord or helpers.

# Good
      module Billing
        class TaxCalculator
          def initialize(amount); @amount = amount; end
          def call; @amount * 0.05; end
        end
      end

3. ✅ Use Value Objects for Repeated Concepts

Instead of passing raw hashes or primitives, use value objects for things like money or address.

Billing::Money.new(amount: 99.99, currency: "USD")

4. ✅ One Command = One Action

Each command object should encapsulate one clear business action.

# app/domains/users/register_user_command.rb
      class RegisterUserCommand
        def initialize(params); @params = params; end
        def call; User.create!(@params); end
      end

5. ✅ Keep Controllers Thin

Use domain commands or services to handle business logic.

# app/controllers/users_controller.rb
      def create
        @user = Users::RegisterUserCommand.new(user_params).call
        redirect_to @user
      end

6. ✅ Isolate Bounded Contexts

Never share models or services across contexts like Inventory and Billing.

7. ✅ Use Explicit Return Types (Success/Failure)

Use dry-monads or similar to return structured results instead of booleans or nil.

result = Billing::CreateInvoiceCommand.new(order).call
      if result.success?
        redirect_to result.value!
      else
        flash[:alert] = result.failure
      end

8. ✅ Test Domains in Isolation

Write RSpec unit tests for domain classes, not for Rails controllers or helpers.

RSpec.describe Billing::TaxCalculator do
        it "calculates 5% tax" do
          expect(described_class.new(100).call).to eq(5.0)
        end
      end

9. ✅ Avoid Fat Models, Use Aggregates Instead

Model relationships inside aggregates and use methods like add_item or calculate_total.

10. ✅ Reflect Ubiquitous Language in Code

Use domain terms your business uses. If your business says “fulfill order”, don’t name the method process_cart.

🌍 Real-World Use Cases

• 🛒 E-commerce apps separating Checkout, Inventory, and Shipping
• 🏥 Healthcare systems isolating Patient, Diagnosis, and Billing contexts
• 🏦 Banking apps with Loans, Accounts, Payments as separate domains

🧠 Detailed Explanation – Fat Model, Skinny Controller

Fat Model, Skinny Controller is a common Rails practice that helps keep your code clean, organized, and easy to manage.

🧾 What does it mean?

It means putting most of your business logic (the rules and behavior of your app) inside your Model files, instead of in your Controller files.

Controllers should only:

• Accept requests from the browser (like "create user" or "place order")
• Call the model to do the work
• Return a response (like redirect or render a page)

Models should handle all the actual work, like:

• Validating input
• Saving data
• Sending emails
• Calculating totals
• Running complex logic

📦 Example – Before and After

❌ Bad: Fat Controller

# users_controller.rb
    def create
      @user = User.new(params[:user])
      if @user.save
        UserMailer.welcome(@user).deliver_later
        Analytics.track_signup(@user)
        redirect_to @user
      else
        render :new
      end
    end

This controller is doing too much: saving the user, sending mail, tracking analytics.

✅ Good: Fat Model

# users_controller.rb
    def create
      @user = User.register(params[:user])
      if @user.persisted?
        redirect_to @user
      else
        render :new
      end
    end

# user.rb
    def self.register(attrs)
      user = new(attrs)
      if user.save
        UserMailer.welcome(user).deliver_later
        Analytics.track_signup(user)
      end
      user
    end

This is better! The controller is simple, and the model takes care of the business logic.

🎯 Why do we use it?

• ✅ Makes controllers easier to read
• ✅ Keeps logic in one place (the model)
• ✅ Makes it easier to test and reuse your logic
• ✅ Follows the principle: “Skinny Controller, Fat Model”

🤔 What if my model gets too fat?

That’s okay! You can move complex logic into:

• Service objects (e.g., UserSignupService)
• Form objects (e.g., RegistrationForm)
• Command classes (e.g., CreateUserCommand)

This way, your logic is still out of the controller and easy to manage.

📌 Summary

• Controllers = Thin, only handle input/output
• Models = Handle core logic and rules
• If logic gets big, move it to plain Ruby objects (services, commands)

📘 Key Terms & Concepts – Fat Model, Skinny Controller

🔁 Flow – How Fat Model, Skinny Controller Works

1. 1. Request Comes In:
   A user submits a form or clicks a link, and Rails routes the request to a controller action.
2. 2. Controller Handles Request:
   The controller receives input (like params) and delegates the real work to a model method or service object.
3. 3. Model Executes Business Logic:
   The model validates data, performs calculations, sends emails, saves records, or interacts with other models.
4. 4. Controller Responds:
   Once the model finishes, the controller renders a view or redirects to another page.
5. 5. Result Is Shown:
   The user sees the result (success message, new page, or error).

✅ The main rule: Controller = Light Logic + Routing and Model = All Core Logic

📌 Where & How to Use This Pattern

📌 Pro Tip: Use this pattern for 90% of your Rails actions unless the logic is so complex that it needs its own object or module.

🧩 Gems & Libraries – Fat Model, Skinny Controller in Rails

🛠️ Best Implementation – Fat Model, Skinny Controller in Rails

This example shows how to apply the Fat Model, Skinny Controller pattern by moving business logic out of the controller and into the model (or a service object if the logic is complex).

📁 Step 1: Problem Example – Fat Controller

This is how many developers start: putting everything in the controller, which becomes hard to manage and test.

# app/controllers/users_controller.rb
    def create
      @user = User.new(user_params)
      if @user.save
        UserMailer.welcome(@user).deliver_later
        AnalyticsService.track_signup(@user)
        flash[:notice] = "User created successfully!"
        redirect_to @user
      else
        render :new
      end
    end

👎 This controller does too much: validation, saving, mailing, tracking, and UI handling.

✅ Step 2: Move Logic to the Model

Move all the logic into a class method in the model (e.g., User.register).

# app/models/user.rb
    class User < ApplicationRecord
      validates :email, presence: true, uniqueness: true
      validates :password, presence: true
    
      def self.register(params)
        user = new(params)
        if user.save
          UserMailer.welcome(user).deliver_later
          AnalyticsService.track_signup(user)
        end
        user
      end
    end

✅ Step 3: Make the Controller Clean

Now the controller is focused only on request/response, not business logic.

# app/controllers/users_controller.rb
    def create
      @user = User.register(user_params)
      if @user.persisted?
        redirect_to @user, notice: "User created!"
      else
        render :new
      end
    end

👍 This controller is readable, testable, and follows the SRP (Single Responsibility Principle).

🔁 Step 4: What If Logic Is Too Big?

If the logic grows too large, extract it into a Service Object instead of stuffing it in the model.

# app/services/user_registration_service.rb
    class UserRegistrationService
      def initialize(params)
        @params = params
      end
    
      def call
        user = User.new(@params)
        if user.save
          UserMailer.welcome(user).deliver_later
          AnalyticsService.track_signup(user)
        end
        user
      end
    end

# app/controllers/users_controller.rb
    def create
      @user = UserRegistrationService.new(user_params).call
      if @user.persisted?
        redirect_to @user
      else
        render :new
      end
    end

🧪 Step 5: Add Tests

# spec/services/user_registration_service_spec.rb
    RSpec.describe UserRegistrationService do
      let(:params) { { email: "[email protected]", password: "secret" } }
    
      it "creates a user and sends email" do
        expect {
          service = UserRegistrationService.new(params)
          user = service.call
        }.to change(User, :count).by(1)
         .and change { ActionMailer::Base.deliveries.count }.by(1)
      end
    end

📌 Summary of Best Practices

• ✅ Keep controller actions short (ideally under 10 lines)
• ✅ Move all logic into models or service objects
• ✅ Use value objects or command classes when logic grows
• ✅ Write unit tests for the model/service, not the controller

💡 Example

# ❌ Bad – Logic inside Controller
def create
  @user = User.new(params[:user])
  if @user.save
    UserMailer.welcome(@user).deliver_later
    redirect_to @user
  else
    render :new
  end
end

# ✅ Good – Logic moved to Model or Service
def create
  @user = User.register(params[:user])
  if @user.persisted?
    redirect_to @user
  else
    render :new
  end
end

# In Model:
def self.register(attrs)
  user = new(attrs)
  if user.save
    UserMailer.welcome(user).deliver_later
  end
  user
end

🔁 Alternative Concepts

• Service Objects: Move complex logic from models to `app/services`
• Interactor Pattern: Use `interactor` gem to encapsulate operations

🛠️ Technical Q&A – Fat Model, Skinny Controller in Rails

Q1: What is the Fat Model, Skinny Controller pattern?

A: It’s a Rails architectural practice where controllers only handle routing and responses, while models (or service objects) contain the application's business logic. This keeps controllers simple and models powerful.

Q2: Why is this pattern preferred in Rails?

A: Because it follows the Single Responsibility Principle — each class or file should do one job. Controllers should handle HTTP requests; models handle logic like validations, data changes, or notifications.

Q3: How do I move logic from controller to model?

A: Create a method in your model (class or instance method), and move logic into it. Example:

# Controller
    @user = User.register(user_params)
    
    # Model
    def self.register(params)
      user = new(params)
      user.save
      UserMailer.welcome(user).deliver_later
      user
    end

Q4: What if my model becomes too large?

A: Use Service Objects or Command Objects to extract logic from the model. Example:

# app/services/user_signup_service.rb
    class UserSignupService
      def initialize(params); @params = params; end
    
      def call
        user = User.new(@params)
        user.save
        Analytics.track_signup(user)
        user
      end
    end

Q5: Can we use this pattern with callbacks?

A: You can, but use callbacks carefully. Avoid hiding logic in callbacks unless it’s tightly related to saving records (like timestamps or normalizations).

# Good use of callback
    before_save :normalize_email
    
    def normalize_email
      self.email = email.downcase
    end

Q6: How do I test logic moved to the model?

A: You write **unit tests** for model methods or service objects instead of controller tests. Example:

RSpec.describe User, type: :model do
      it "sends welcome email when registering" do
        expect {
          User.register({email: "[email protected]", password: "secret"})
        }.to change { ActionMailer::Base.deliveries.count }.by(1)
      end
    end

Q7: What’s a common beginner mistake with this pattern?

A: Putting logic back into controllers during refactoring, like handling side effects or errors there. Keep logic in the model/service, and just handle success/failure in the controller.

Q8: When should I choose a service object over a fat model?

A: When logic touches multiple models or becomes long (e.g., multi-step processes), extract it into a service. Rule of thumb: if a method is >15–20 lines or uses multiple `if`/`else` paths, move it.

Q9: What gem can help structure this pattern better?

A: Use interactor or service_pattern gems to structure business logic cleanly outside models and controllers.

# Interactor example
    class RegisterUser
      include Interactor
    
      def call
        user = User.new(context.params)
        user.save!
        UserMailer.welcome(user).deliver_later
        context.user = user
      end
    end

Q10: Does this pattern apply only to models?

A: No. If your business logic doesn't belong to one model, use POROs (Plain Old Ruby Objects), Services, or Interactors. The idea is to **separate concerns** — not to make the model a dumping ground.

✅ Best Practices with Examples – Fat Model, Skinny Controller in Rails

1. ✅ Keep Controllers Thin and Focused

Controllers should only receive input, delegate work, and return a response.

# Good
    def create
      @user = User.register(user_params)
      redirect_to @user
    end

2. ✅ Move Complex Logic into the Model

Business rules, email sending, and calculations should live in the model or a service.

# user.rb
    def self.register(params)
      user = new(params)
      if user.save
        UserMailer.welcome(user).deliver_later
      end
      user
    end

3. ✅ Use Service Objects for Multi-Model Logic

If logic involves more than one model or external API, create a class in app/services/.

# app/services/create_order.rb
    class CreateOrder
      def initialize(user, cart)
        @user = user
        @cart = cart
      end
    
      def call
        order = Order.create!(user: @user)
        @cart.items.each do |item|
          order.line_items.create!(product: item.product, quantity: item.quantity)
        end
        order
      end
    end

4. ✅ Reuse Business Logic with Model Methods

Make common actions callable like user.send_welcome_email.

# user.rb
    def send_welcome_email
      UserMailer.welcome(self).deliver_later
    end

5. ✅ Use Plain Ruby Objects (POROs) When Needed

Not everything needs to be a model. Use regular Ruby classes when logic doesn’t belong to ActiveRecord.

# app/lib/tax_calculator.rb
    class TaxCalculator
      def initialize(amount); @amount = amount; end
      def call; @amount * 0.05; end
    end

6. ✅ Avoid Hidden Logic in Callbacks

Callbacks like after_save can make code hard to debug. Prefer explicit method calls in your model or service.

# ❌ Hidden in callback
    after_save :send_invoice
    
    # ✅ Better
    def complete_order
      save!
      InvoiceMailer.send_invoice(self).deliver_later
    end

7. ✅ Add Unit Tests for Models and Services

Test your logic outside the controller. Controller tests should be minimal.

# spec/services/create_order_spec.rb
    RSpec.describe CreateOrder do
      it "creates an order with items" do
        order = CreateOrder.new(user, cart).call
        expect(order.line_items.count).to eq(cart.items.count)
      end
    end

8. ✅ Name Service Classes with a Verb

Use clear names like CreateInvoice, RegisterUser, SyncPayments.

# app/services/sync_payments.rb
    class SyncPayments
      def initialize(account); @account = account; end
      def call; ... end
    end

9. ✅ Group Files by Responsibility

Use folders like app/services, app/lib, or app/forms to separate logic clearly.

app/
    ├── controllers/
    ├── models/
    ├── services/
    │   └── register_user.rb
    ├── mailers/
    ├── forms/
    ├── lib/

10. ✅ Keep Code Intentional and Readable

Your code should clearly express intent. The controller should say “register user”, not “create user and send mail and do analytics”.

# Good
    User.register(params)

🌍 Real-World Use Cases

• 📩 Signup flows where email confirmation, billing, and profile setup are handled in models/services
• 🛒 Checkout flow – price calculation, stock updates go into model logic

🧠 Detailed Explanation – Hexagonal Architecture (Ports & Adapters)

Hexagonal Architecture, also called Ports and Adapters, is a way of organizing your code so that your core application logic is protected from outside systems like databases, web controllers, APIs, or third-party libraries.

Imagine your app is a **hexagon (or a circle)** in the center, surrounded by the outside world. You talk to the outside world through **ports** (interfaces), and the outside world connects to you through **adapters** (implementations).

🔌 What are Ports?

Ports are just interfaces. They define how the core logic expects to talk to things like databases, emails, or APIs. The core doesn’t care how these things are actually implemented.

# port: order_repo.rb (interface)
    class OrderRepo
      def save(order)
        raise NotImplementedError
      end
    end

🧩 What are Adapters?

Adapters are real implementations of those interfaces. For example, one adapter might use ActiveRecord to save data; another might use a JSON API.

# adapter: order_repository.rb (implements the port)
    class OrderRepository < OrderRepo
      def save(order)
        OrderRecord.create!(order.attributes)
      end
    end

🏗️ Core Logic Example

The main logic lives in a service object or use case. It depends on ports (not Rails).

# core/use_cases/create_order.rb
    class CreateOrder
      def initialize(order_repo, notifier)
        @order_repo = order_repo
        @notifier = notifier
      end
    
      def call(data)
        order = Order.new(data)
        @order_repo.save(order)
        @notifier.send("Order created successfully!")
      end
    end

Notice: The core doesn’t care about database, email, or Rails. It just does its job.

🚪 Why use Hexagonal Architecture?

• ✅ You can test business logic easily (mock ports)
• ✅ You can change frameworks or tools without breaking the core
• ✅ You keep Rails details out of your logic
• ✅ Your app becomes easier to understand and extend

📌 Analogy

Think of your app like a power plug:

• 🔌 Port: The plug socket (interface)
• ⚙️ Adapter: The plug that fits into the socket
• 🔋 Core: Your actual device that runs regardless of how it’s powered

🔁 Summary

• ✅ Core logic depends on ports (interfaces)
• ✅ Outside systems use adapters to implement those ports
• ✅ Makes your code clean, testable, and flexible
• ✅ Great for large or long-term Rails apps

📘 Key Terms & Concepts – Hexagonal Architecture (Ports & Adapters)

🔁 Flow – How Hexagonal Architecture Works

1. 1. A Request Comes In:
   A user sends a request (e.g., via web, API, or CLI) that is handled by an inbound adapter such as a Rails controller.
2. 2. The Adapter Calls a Port (Interface):
   The adapter calls a port (interface), which connects to the core business logic — like a use case class.
3. 3. The Core Logic Executes:
   The core logic (use case) performs business operations, using other ports like `Repository` or `Notifier` if needed.
4. 4. The Core Calls Outbound Adapters:
   The core logic sends data to an outbound adapter — like a database adapter or an email sender.
5. 5. The Result Is Returned:
   The controller (inbound adapter) receives the result and responds to the user (e.g., render view, JSON, or redirect).

📌 Key Idea: The core logic never knows if it’s being called by a web app, CLI, or test — it only talks to interfaces (ports).

📌 Where & How to Use Hexagonal Architecture in Rails Apps

✅ Rule of Thumb: Use Hexagonal Architecture when your logic grows beyond simple CRUD, or when you want testability, flexibility, and long-term maintainability.

🧩 Gems & Libraries – Hexagonal Architecture in Rails

🛠️ Best Implementation – Hexagonal Architecture in Rails

This example shows how to implement Hexagonal Architecture by cleanly separating core logic from external systems like databases and notifications using ports and adapters.

📁 Step 1: Folder Structure

app/
    ├── core/
    │   └── use_cases/
    │       └── create_order.rb
    ├── domains/
    │   └── order.rb
    ├── ports/
    │   ├── order_repository.rb
    │   └── notifier.rb
    ├── adapters/
    │   ├── repositories/
    │   │   └── active_record_order_repository.rb
    │   └── notifiers/
    │       └── email_notifier.rb
    ├── controllers/
    │   └── orders_controller.rb

Each layer is separated by responsibility: core logic, domain model, ports (interfaces), and adapters (implementations).

📦 Step 2: Define a Domain Model (Entity)

# app/domains/order.rb
    class Order
      attr_reader :id, :user_id, :items, :total
    
      def initialize(user_id:, items:)
        @user_id = user_id
        @items = items
        @total = calculate_total
      end
    
      private
    
      def calculate_total
        items.sum { |item| item[:price] * item[:quantity] }
      end
    end

🛣️ Step 3: Define Ports (Interfaces)

# app/ports/order_repository.rb
    class OrderRepository
      def save(order)
        raise NotImplementedError
      end
    end
    
    # app/ports/notifier.rb
    class Notifier
      def send(message)
        raise NotImplementedError
      end
    end

⚙️ Step 4: Core Use Case (Business Logic)

# app/core/use_cases/create_order.rb
    class CreateOrder
      def initialize(order_repository:, notifier:)
        @order_repository = order_repository
        @notifier = notifier
      end
    
      def call(user_id:, items:)
        order = Order.new(user_id: user_id, items: items)
        @order_repository.save(order)
        @notifier.send("Order created for user #{user_id}")
        order
      end
    end

🔌 Step 5: Implement Adapters

# app/adapters/repositories/active_record_order_repository.rb
    class ActiveRecordOrderRepository < OrderRepository
      def save(order)
        OrderRecord.create!(
          user_id: order.user_id,
          total: order.total,
          items_data: order.items.to_json
        )
      end
    end
    
    # app/adapters/notifiers/email_notifier.rb
    class EmailNotifier < Notifier
      def send(message)
        NotificationMailer.system_alert(message).deliver_later
      end
    end

🧠 Step 6: Wire It Up in Controller

# app/controllers/orders_controller.rb
    class OrdersController < ApplicationController
      def create
        repository = ActiveRecordOrderRepository.new
        notifier = EmailNotifier.new
    
        use_case = CreateOrder.new(order_repository: repository, notifier: notifier)
        order = use_case.call(user_id: params[:user_id], items: params[:items])
    
        render json: { status: "success", order_total: order.total }
      end
    end

🧪 Step 7: Test the Core Logic

# spec/use_cases/create_order_spec.rb
    RSpec.describe CreateOrder do
      let(:fake_repo) { instance_double("OrderRepository", save: true) }
      let(:fake_notifier) { instance_double("Notifier", send: true) }
    
      it "creates an order and sends a notification" do
        use_case = CreateOrder.new(order_repository: fake_repo, notifier: fake_notifier)
        order = use_case.call(user_id: 1, items: [{ price: 10, quantity: 2 }])
    
        expect(order.total).to eq(20)
        expect(fake_repo).to have_received(:save).with(order)
        expect(fake_notifier).to have_received(:send).with("Order created for user 1")
      end
    end

✅ Summary

• 💡 Core logic lives in app/core/use_cases
• 🔌 External dependencies use ports and adapters
• 🧪 Tests mock ports to test logic in isolation
• 🔁 Adapters can be swapped without touching the core logic
• 🚫 No ActiveRecord or Rails dependency inside business logic

💡 Example

# Core Use Case
# app/core/use_cases/create_order.rb
class CreateOrder
  def initialize(order_repo, notifier)
    @order_repo = order_repo
    @notifier = notifier
  end

  def call(data)
    order = Order.new(data)
    @order_repo.save(order)
    @notifier.send("Order created")
  end
end

# Adapter: Repository
# app/adapters/repositories/order_repository.rb
class OrderRepository
  def save(order)
    OrderRecord.create!(order.attributes)
  end
end

# Adapter: Notifier
# app/adapters/notifiers/email_notifier.rb
class EmailNotifier
  def send(message)
    EmailService.deliver(message)
  end
end

🔁 Alternative Concepts

• Service Layer: Simpler but often mixes logic and I/O
• Onion Architecture: Very similar, but layers are enforced inward
• Clean Architecture: Modern evolution with interactor/input/output terminology

🛠️ Technical Q&A – Hexagonal Architecture in Rails

Q1: What is Hexagonal Architecture?

A: It’s an architectural pattern that separates your core application logic from the external world (UI, database, APIs). The app communicates through "Ports" (interfaces) and "Adapters" (implementations).

Q2: What are Ports and Adapters?

A: A Port is an interface that the core logic depends on. An Adapter is a class that implements that interface to connect to external systems.

# Port
    class Notifier
      def send(message)
        raise NotImplementedError
      end
    end
    
    # Adapter
    class EmailNotifier < Notifier
      def send(message)
        Mailer.deliver(message)
      end
    end

Q3: Why is Hexagonal Architecture useful in Rails apps?

A: It improves testability, flexibility, and separation of concerns. Your core logic becomes independent of Rails (e.g., ActiveRecord, ActionMailer).

Q4: How do you test core logic in Hexagonal Architecture?

A: You test the core use cases by mocking the adapters (ports), without touching the database or Rails internals.

# spec/use_cases/create_order_spec.rb
    let(:repo) { double("OrderRepository", save: true) }
    let(:notifier) { double("Notifier", send: true) }
    
    it "creates an order and notifies" do
      use_case = CreateOrder.new(order_repository: repo, notifier: notifier)
      use_case.call(user_id: 1, items: [{ price: 10, quantity: 2 }])
      
      expect(repo).to have_received(:save)
      expect(notifier).to have_received(:send)
    end

Q5: Can Hexagonal Architecture be overkill for small apps?

A: Yes. For small CRUD apps, the overhead may not be worth it. But it shines in apps with growing complexity or multiple external integrations.

Q6: What’s the difference between Inbound and Outbound Adapters?

A:

• Inbound Adapters: Bring data into the system (e.g., web controllers, API endpoints)
• Outbound Adapters: Used by the system to reach external services (e.g., database repo, mailer)

Q7: How do you inject dependencies (adapters) into use cases?

A: Pass them through the constructor or use dependency injection tools like dry-container.

# Manual DI
    repo = ActiveRecordOrderRepository.new
    notifier = EmailNotifier.new
    use_case = CreateOrder.new(order_repository: repo, notifier: notifier)

Q8: How does Hexagonal Architecture improve testing?

A: Core logic becomes testable in isolation, without needing to hit the database or APIs. This leads to faster and more reliable tests.

Q9: Can I still use ActiveRecord and ActionMailer?

A: Yes, but only inside the adapter layer. The core logic should never directly access them.

Q10: How do I structure Hexagonal Architecture in Rails?

A: Follow this common directory pattern:

app/
    ├── core/            # Use cases
    ├── domains/         # Domain models (entities)
    ├── ports/           # Interfaces
    ├── adapters/        # Implementations (DB, mail, APIs)
    ├── controllers/     # Inbound Adapters (e.g., HTTP)

✅ Best Practices with Examples – Hexagonal Architecture in Rails

1. ✅ Keep Core Logic Free from Rails

Your use case classes (core logic) should not depend on ActiveRecord, ActionMailer, or Rails concerns.

# Good
    def call(user_id:, items:)
      order = Order.new(user_id: user_id, items: items)
      @repo.save(order)
    end
    
    # Bad
    OrderRecord.create(user_id: ..., total: ...)

2. ✅ Define Clear Interfaces (Ports)

Use Ruby interfaces (abstract classes or modules) to define what your adapters must implement.

# port/notifier.rb
    class Notifier
      def send(message)
        raise NotImplementedError
      end
    end

3. ✅ Use Adapters for External Systems

All external system access (e.g., database, email, payment gateway) should go through an adapter.

# adapters/repositories/active_record_order_repository.rb
    class ActiveRecordOrderRepository
      def save(order)
        OrderRecord.create!(user_id: order.user_id, total: order.total)
      end
    end

4. ✅ Use Constructor Injection for Dependencies

Pass ports (interfaces) into use case classes via constructor injection.

# controller
    use_case = CreateOrder.new(
      order_repository: ActiveRecordOrderRepository.new,
      notifier: EmailNotifier.new
    )
    use_case.call(...)

5. ✅ Test Core Logic in Isolation

Mock all adapters when testing core logic. Never hit the database or send emails in unit tests.

# RSpec
    let(:repo) { instance_double("OrderRepository", save: true) }
    let(:notifier) { instance_double("Notifier", send: true) }

6. ✅ Use Plain Ruby Objects (POROs) for Entities

Your domain models should be framework-independent and only represent business data.

# domains/order.rb
    class Order
      attr_reader :user_id, :items, :total
      def initialize(user_id:, items:)
        @user_id = user_id
        @items = items
        @total = items.sum { |i| i[:price] * i[:quantity] }
      end
    end

7. ✅ Keep Use Cases Focused

Each use case should do one thing: place order, send email, register user. Avoid mixing multiple responsibilities.

# app/core/use_cases/send_invoice.rb
    class SendInvoice
      def initialize(invoice_repo, mailer)
        @invoice_repo = invoice_repo
        @mailer = mailer
      end
    
      def call(invoice_id)
        invoice = @invoice_repo.find(invoice_id)
        @mailer.send_invoice(invoice)
      end
    end

8. ✅ Organize Code by Role, Not Layer

Structure your app by roles (core, ports, adapters), not traditional MVC folders. This improves separation and clarity.

app/
    ├── core/
    ├── ports/
    ├── adapters/
    ├── domains/
    ├── controllers/

9. ✅ Document Ports and Adapters Clearly

Explain what each port is responsible for, and which adapter implements it. This is critical when scaling or onboarding new devs.

10. ✅ Use Hexagonal Only Where It Makes Sense

For simple CRUD, you may not need full hexagonal structure. Start applying it to complex workflows and critical business logic first.

🌍 Real-World Use Case

• 🛍 E-commerce: Placing orders via web or API using the same `CreateOrder` use case
• 📬 Email & SMS: Notifications can be swapped by changing the adapter
• 📊 Analytics: Core logic tracks metrics through a `Tracker` port, not tied to a specific tool

🧠 Detailed Explanation – Microservices in Rails

Microservices is an architectural pattern where a large application is split into small, independent services. Each service focuses on a single feature or business task — like managing users, handling orders, or sending emails.

Instead of building one big Rails app (called a monolith), you create multiple small Rails apps that talk to each other via APIs (HTTP) or background jobs (Sidekiq, Redis).

🏗️ What it looks like:

• User Service: Handles login, registration, authentication
• Order Service: Manages cart, checkout, payments
• Notification Service: Sends email, SMS, and in-app messages

Each service has its own codebase, its own database, and can be deployed separately.

🚀 Why Use Microservices?

• ✅ Services can be deployed independently
• ✅ Smaller codebases are easier to manage
• ✅ Teams can work on different services without stepping on each other
• ✅ Easier to scale parts of your system (e.g., just the order service)

❗ Things to Be Careful About

• ⚠️ More services = more complexity (especially communication)
• ⚠️ Requires good monitoring, logging, and DevOps skills
• ⚠️ Difficult to manage transactions across services

🔗 How Services Communicate

• Synchronous: REST APIs or GraphQL (e.g., `POST /api/orders`)
• Asynchronous: Background jobs, message queues (e.g., RabbitMQ, Kafka, Sidekiq)

# Example: Calling another service
    HTTParty.post("http://notification-service.local/send", 
      body: { email: "[email protected]", message: "Order confirmed" }.to_json)

📦 Summary

• ✅ Microservices = many small apps that do one thing well
• ✅ Services talk to each other via APIs or queues
• ✅ Each service has its own database
• ✅ Best for teams, scale, and complex systems

📘 Key Terms & Concepts – Microservices in Rails

🔁 Flow Section – How Microservices Work in Rails

Microservices follow a simple pattern: each service does one job well and talks to others via APIs or background jobs. Here's how the flow works:

1. 1. User sends a request to the frontend or API Gateway
2. 2. API Gateway routes the request to the correct microservice (e.g., to the OrderService)
3. 3. The microservice processes its own logic (e.g., creating an order, saving it in its own database)
4. 4. If needed, the microservice calls other services (e.g., calls NotificationService to send an order confirmation email)
5. 5. Each service responds back with success or failure
6. 6. The frontend or API Gateway shows the final response to the user

🧭 Example Use Case Flow (Ordering System)

1. User clicks "Place Order" on the UI
2. OrderService receives the request and creates the order
3. OrderService notifies PaymentService to process payment
4. Once payment is done, NotificationService sends a confirmation email
5. Each service logs its action independently and stores its own data

🏢 Where We Use Microservices in Rails

• ✅ E-commerce platforms: Split cart, inventory, payments, and review systems
• ✅ Healthcare apps: Separate patient records, billing, appointments, and doctor profiles
• ✅ Messaging systems: Microservices for auth, chat, file upload, and analytics
• ✅ SAAS products: Billing, user accounts, notifications, and analytics services
• ✅ ERP systems: Finance, HR, CRM, and Supply Chain modules as microservices

📌 Summary of Flow

• 📦 Each microservice handles one function independently
• 🔗 Communication happens via APIs or message queues
• 🔒 Each service is isolated with its own data, logic, and deployments
• 💡 Failures in one service should not crash others (if designed well)

📦 Gems & Libraries Used in Rails Microservices

Microservices in Rails rely on a combination of Ruby gems and infrastructure tools to enable independent services, communication, and deployment.

Note: Not all gems are required for every Rails microservice. Choose based on whether you're using REST, GraphQL, or background jobs.

🚀 Best Implementation – Microservices in Rails

This example shows how to break a large Rails monolith into 3 services:

• AuthService: Handles user signup, login, JWT
• OrderService: Handles product orders and payments
• NotificationService: Sends emails and SMS

🧱 Step-by-Step Implementation

1. Create separate Rails apps: Each microservice is its own Rails app.

   rails new auth_service --api
       rails new order_service --api
       rails new notification_service --api

2. Each service has its own DB: Use PostgreSQL or MySQL.
   config/database.yml should be different per service.
3. Use JWT for authentication: AuthService issues tokens.

   # AuthService: Generate JWT
       JWT.encode({ user_id: user.id }, Rails.application.secrets.secret_key_base)

4. OrderService validates token:

   # Decode token in a before_action
       token = request.headers["Authorization"].split.last
       decoded = JWT.decode(token, Rails.application.secrets.secret_key_base)[0]

5. Use HTTParty or Faraday to call other services:

   # OrderService -> NotificationService
       HTTParty.post("http://localhost:3003/api/v1/notifications", 
         body: { email: user.email, message: "Order placed" }.to_json,
         headers: { "Content-Type": "application/json" })

6. Use Sidekiq for async communication: When you don’t need an immediate response.

   # In OrderService
       NotificationJob.perform_later(user.email, "Order received")

7. Run services using Docker:

   # Dockerfile
       FROM ruby:3.2
       WORKDIR /app
       COPY . .
       RUN bundle install
       CMD ["rails", "server", "-b", "0.0.0.0"]

8. Optional: Use Kubernetes or Docker Compose to manage all services together.

📦 Folder Structure for One Microservice

order_service/
    ├── app/
    │   └── controllers/
    │       └── api/
    │           └── v1/
    │               └── orders_controller.rb
    ├── jobs/
    │   └── notification_job.rb
    ├── config/
    ├── Gemfile
    ├── Dockerfile

✅ Tips for Clean Design

• ✅ Each service is testable and deployable separately
• ✅ Use internal API keys or JWT for service communication
• ✅ Use message queues for scalability (e.g., Sidekiq + Redis)
• ✅ Avoid shared databases across services

📌 Final Output Example

User signs up at AuthService → gets token → places order at OrderService → which calls NotificationService to send confirmation email.

💡 Example

Split a Rails monolith into:

• Auth Service: Manages users, login, OAuth
• Order Service: Handles orders, payments
• Notification Service: Sends emails/SMS

# Example communication (Auth Service -> Order Service)
HTTParty.post("http://order-service.local/api/orders", body: order_params.to_json)

🔁 Alternative Concepts

• Monolith: One big Rails app (easier for small teams)
• Modular Monolith: Structured modules in one app, with internal boundaries
• SOA: Service-Oriented Architecture (more loosely coupled than microservices)

💬 Technical Questions and Answers – Microservices in Rails

# OrderService sends a POST request to NotificationService
    HTTParty.post("http://notification_service:3003/api/send", 
      body: { email: "[email protected]", message: "Order Confirmed" }.to_json,
      headers: { "Content-Type": "application/json" })

# AuthService: create token
    token = JWT.encode({ user_id: user.id }, Rails.application.secrets.secret_key_base)
    
    # OrderService: decode token
    decoded = JWT.decode(token, Rails.application.secrets.secret_key_base)[0]

# Stub NotificationService call in OrderService spec
    stub_request(:post, "http://notification_service:3003/api/send")
      .to_return(status: 200, body: "", headers: {})

# In OrderService
    NotificationJob.perform_later(user.id, "Your order is confirmed!")

# In Docker Compose
    notification_service:
      build: .
      ports:
        - "3003:3000"
    
    # Services access it using: http://notification_service:3000

# Create a shared gem
    module CurrencyConverter
      def self.usd_to_eur(amount)
        amount * 0.92
      end
    end

✅ Best Practices – Microservices in Rails

Microservices offer flexibility and scale, but can also bring complexity. Below are proven best practices to follow when using Rails for microservices — along with real examples.

1️⃣ One Responsibility per Service

Each service should manage one business function. Avoid the temptation to add unrelated features.

# Good: user_service handles only authentication & registration
    # Bad: user_service also sends emails, handles payments

2️⃣ Separate Databases per Service

Never share databases. Let each service own its own data to avoid tight coupling.

# Good: AuthService has its own PostgreSQL DB
    # Bad: AuthService and OrderService write to the same DB table

3️⃣ Use JWT for Stateless Authentication

Issue a token once from AuthService and verify it in other services without sharing sessions.

# AuthService
    JWT.encode({ user_id: 1 }, Rails.application.secret_key_base)
    
    # Other service
    JWT.decode(token, Rails.application.secret_key_base)

4️⃣ Prefer Asynchronous Messaging

Don’t block the user flow by waiting for other services. Use background jobs and message queues.

# Good: Notify via Sidekiq
    NotificationJob.perform_later("Order confirmed")
    
    # Bad: Wait for email service to respond during checkout

5️⃣ Use API Gateways or Internal DNS

Route external traffic using an API Gateway. Use internal hostnames (Docker/Kubernetes) for service discovery.

# In Docker Compose
    http://notification_service:3000/api/send

6️⃣ Use Semantic Versioning for APIs

Version your APIs clearly to avoid breaking other services unexpectedly.

# Good:
    POST /api/v1/orders
    # Future:
    POST /api/v2/orders

7️⃣ Avoid Overcommunication

Only call another service when necessary. Duplicate minimal data if needed to reduce calls.

# Good: Save order_summary in local DB
    # Bad: Fetch user details from AuthService on every request

8️⃣ Fail Gracefully

Always handle errors between services to avoid cascading failures.

begin
      HTTParty.post("http://notification_service/api")
    rescue => e
      Rails.logger.error("Notification failed: #{e.message}")
    end

9️⃣ Use Health Checks and Monitoring

Set up a `/health` route in each service for liveness checks. Use Prometheus or CloudWatch for metrics.

# config/routes.rb
    get "/health", to: proc { [200, {}, ["OK"]] }

🔟 Dockerize Every Service

Each Rails microservice should be containerized for isolation, easy deployment, and scaling.

# Dockerfile
    FROM ruby:3.2
    WORKDIR /app
    COPY . .
    RUN bundle install
    CMD ["rails", "server", "-b", "0.0.0.0"]

🌍 Real-World Use Cases

• 🛍 E-commerce: Separate services for users, orders, payments, reviews
• 💬 Messaging Platforms: Chat, auth, analytics, and notifications as separate apps
• 🏥 Healthcare: Patient management, scheduling, and billing split into services

🧠 Detailed Explanation – Singleton Pattern in Rails

The Singleton Pattern is a design pattern that ensures only one object of a class can ever be created — and it gives you a simple way to access that object from anywhere in your app.

In Rails (and Ruby), you might use Singleton when you need just one "manager" or "controller" object — for example:

• 📋 A configuration loader (like reading settings from YAML)
• 🧾 A logger that writes to a log file
• 📊 A metrics or stats collector

💡 Ruby provides a built-in module called Singleton to make this pattern easy to implement. You don’t need to manually handle instance tracking — just include the module!

require 'singleton'

class AppLogger
  include Singleton

  def log(msg)
    puts "[LOG] #{msg}"
  end
end

AppLogger.instance.log("App started!")

🔁 Now, every time you call AppLogger.instance, you’re using the same object — no matter where you are in the app.

🧠 Key Benefits

• ✅ You never accidentally create multiple objects
• ✅ Centralized control — perfect for shared services
• ✅ Built-in Singleton module makes it safe and thread-aware

🚫 When Not to Use

• ⚠️ If your object holds lots of data that changes — Singleton may lead to side effects
• ⚠️ If you're writing unit tests — Singleton can make mocking harder

Bottom line: Singleton is great for tools, services, and helpers that should exist only once — like a Rails logger or a global config loader.

📘 Key Terms & Concepts – Singleton Pattern

🔁 Flow Section – How the Singleton Pattern Works in Rails

The Singleton Pattern is used when we need one, and only one, instance of a class that can be accessed from anywhere in the application.

Here's a step-by-step flow of how it works in Ruby on Rails:

1. ✅ You create a class and include Ruby's built-in Singleton module.
2. ✅ You call ClassName.instance instead of ClassName.new to get the object.
3. ✅ The first call creates the object and stores it internally.
4. ✅ Any future calls to .instance return the exact same object.
5. ✅ You use this shared object across your entire Rails app.

This ensures that you never have duplicate instances and that shared logic (like logging or config) is centralized.

🧭 Example Usage Flow

# 1. You define a Singleton logger
class AppLogger
  include Singleton

  def log(message)
    puts "[LOG] #{message}"
  end
end

# 2. In your controller or service
AppLogger.instance.log("User signed in")

🔁 Whether you call this from the controller, model, or background job — it’s always the same logger instance.

🏢 Where We Use Singleton in Rails

• ✅ Logger: Centralized logging system for all app events
• ✅ Configuration Loader: Load app settings from YAML once
• ✅ API Client: Single instance to handle external API requests (like Stripe or Twilio)
• ✅ Payment Gateway: Wrap Stripe/PayPal in one shared service
• ✅ Feature Toggle Manager: Manage enabled/disabled features for users
• ✅ Notification Service: One object to handle email/SMS notifications

Reminder: Singleton is best when you want a shared tool or service with consistent state or behavior.

📦 Gems & Libraries Used – Singleton Pattern in Rails

While Ruby provides native support for the Singleton pattern, some useful libraries and gems can complement or extend its behavior in Rails apps:

Note: For most use cases, just including require 'singleton' is enough. Use extra gems only if your app needs dependency management, caching, or configuration loading.

🛠️ Best Implementation – Singleton Pattern in Rails

Below is a detailed and production-ready implementation of the Singleton pattern in a Rails context. We'll implement a logging service that ensures all parts of your app write logs using the same instance.

📁 Step 1: Create a Service Object

Create a new file in your Rails app under app/services/app_logger.rb.

# app/services/app_logger.rb
require 'singleton'

class AppLogger
  include Singleton

  def log(message)
    File.open(Rails.root.join("log", "custom.log"), "a") do |f|
      f.puts "[#{Time.now}] #{message}"
    end
  end
end

✅ This class:

• Includes Singleton to prevent multiple instances
• Appends all logs to log/custom.log

📞 Step 2: Use It Anywhere in Your App

You can use this logger from any part of the app using:

AppLogger.instance.log("User logged in: #{current_user.id}")

This ensures the same object is used every time — no need to create new instances.

💡 Step 3: Add a Shortcut (Optional)

To make the logger easier to call, create an initializer with a shortcut method.

# config/initializers/app_logger.rb
def AppLog
  AppLogger.instance
end

Now you can call:

AppLog.log("Something important happened!")

🧪 Step 4: Test Your Singleton Class

Create a test to ensure only one instance is used:

# test/services/app_logger_test.rb
require 'test_helper'

class AppLoggerTest < ActiveSupport::TestCase
  test "singleton instance always returns same object" do
    a = AppLogger.instance
    b = AppLogger.instance
    assert_equal a.object_id, b.object_id
  end
end

✅ Summary – Best Practices

• ✅ Use Singleton module from Ruby’s stdlib
• ✅ Avoid using new — always access via instance
• ✅ Use for stateless services like loggers, configs, or integrations
• ✅ Add tests to confirm Singleton behavior
• ✅ Keep methods thread-safe if accessed in concurrent jobs

📌 Final Usage Example in Controller

class UsersController < ApplicationController
  def show
    AppLog.log("User #{params[:id]} visited their profile")
    @user = User.find(params[:id])
  end
end

🔁 This log call will use the exact same Singleton object, whether it’s used in controllers, models, or background jobs.

💡 Examples – Singleton Pattern in Rails

The Singleton pattern is useful when you want only one instance of a class shared across your entire Rails app. Below are practical, detailed examples showing how and where Singleton is used in real Rails projects.

📝 Example 1: App Logger (Custom Logging)

Scenario: You want to log custom events (e.g., user sign-in, background job failures) in a single log file.

# app/services/app_logger.rb
    require 'singleton'
    
    class AppLogger
      include Singleton
    
      def log(message)
        File.open(Rails.root.join("log", "custom.log"), "a") do |file|
          file.puts "[#{Time.now}] #{message}"
        end
      end
    end

Usage:

AppLogger.instance.log("User #{user.id} signed in.")

Why Singleton? You don't want multiple loggers writing inconsistently — use one shared instance.

⚙️ Example 2: Global Config Loader

Scenario: You want to load app configuration from YAML once and reuse it everywhere.

# app/services/app_config.rb
    require 'singleton'
    require 'yaml'
    
    class AppConfig
      include Singleton
    
      def settings
        @settings ||= YAML.load_file(Rails.root.join("config", "app_settings.yml"))
      end
    end

Usage:

api_key = AppConfig.instance.settings["api_key"]

Why Singleton? Avoid re-reading the YAML file multiple times — load once and reuse the same object.

📬 Example 3: Notification Dispatcher

Scenario: You want a centralized class that sends email or SMS notifications and ensures consistency.

# app/services/notification_center.rb
    require 'singleton'
    
    class NotificationCenter
      include Singleton
    
      def notify(email, message)
        NotificationMailer.with(email: email, message: message).send_alert.deliver_later
      end
    end

Usage:

NotificationCenter.instance.notify("[email protected]", "Your order has shipped!")

Why Singleton? One central place to handle notification logic — reusable from controllers, jobs, or services.

💵 Example 4: Payment Gateway Wrapper

Scenario: You want to wrap Stripe or PayPal API in a singleton to reuse the same configuration and reduce API setup overhead.

# app/services/payment_gateway.rb
    require 'singleton'
    
    class PaymentGateway
      include Singleton
    
      def charge(user, amount_cents)
        Stripe::Charge.create({
          amount: amount_cents,
          currency: "usd",
          customer: user.stripe_customer_id,
          description: "Purchase from Rails Store"
        })
      end
    end

Usage:

PaymentGateway.instance.charge(current_user, 2000)

Why Singleton? Avoid reinitializing Stripe configs — reuse one service for all billing actions.

🎯 Summary

• ✅ Logger: One file, one writer
• ✅ Config Loader: Load YAML once, use everywhere
• ✅ Notification Center: Reuse logic across components
• ✅ Payment Gateway: One API client, consistent behavior

🔁 Alternative Concepts

• Global Variables: Can provide global state, but are discouraged due to tight coupling.
• Dependency Injection: A more testable alternative where the dependency is passed explicitly.

💬 Technical Questions and Answers – Singleton Pattern in Rails

class Logger
      include Singleton
      def log(msg)
        puts "[LOG] #{msg}"
      end
    end
    
    Logger.instance.log("App started")

require 'singleton'
    
    class MyService
      include Singleton
    end
    
    MyService.instance # ✅ Works
    MyService.new      # ❌ Raises NoMethodError

# Safe to call from Sidekiq or multi-threaded controller actions
    MyLogger.instance.log("Processed in thread #{Thread.current.object_id}")

# app/services/app_logger.rb
    class AppLogger
      include Singleton
    end

test "same object always returned" do
      a = AppLogger.instance
      b = AppLogger.instance
      assert_equal a.object_id, b.object_id
    end

class AppCache
      include Singleton
    
      def clear!
        @cache = {}
      end
    end

# Singleton can store state
    AppLogger.instance.last_message
    
    # Class method can't store instance state

🚫 What Happens If You Try to Create a New Singleton Instance?

When you include Ruby’s built-in Singleton module, it automatically disables the new method. This prevents anyone from accidentally creating multiple instances of the class.

❌ Example: Attempting to Use new

require 'singleton'
    
    class MyService
      include Singleton
    end
    
    MyService.new  # ❌ This will raise an error!

Output:

NoMethodError (private method `new' called for MyService:Class)

✅ Correct Way: Use .instance

You should always access the singleton object using:

MyService.instance  # ✅ This returns the single allowed object

🧠 Why This Matters

• ✔️ Ensures only one instance is created
• ✔️ Prevents accidental misuse of new
• ✔️ Enforces global access pattern

Reminder: If you need multiple instances of a class (like per-user or per-request data), Singleton is not the right pattern.

✅ Best Practices – Singleton Pattern in Rails

When using the Singleton pattern in a Rails app, follow these best practices to ensure safe, maintainable, and testable design:

1️⃣ Use Ruby's Built-In Singleton Module

Instead of writing your own logic, use Ruby's standard Singleton module.

require 'singleton'
    
    class MyLogger
      include Singleton
    end

2️⃣ Avoid Storing Mutable Global State

Singletons should be stateless or read-only. Avoid storing user-specific or request-specific data.

# ❌ Bad: Mutable state (not thread-safe)
    class Counter
      include Singleton
      attr_accessor :count
    end
    
    # ✅ Good: Stateless logger
    class AppLogger
      include Singleton
      def log(msg); puts msg; end
    end

3️⃣ Use Singleton for Reusable Infrastructure

Use for shared services like config loaders, loggers, or third-party wrappers.

AppLogger.instance.log("Order created")
    AppConfig.instance.settings["api_key"]

4️⃣ Access Singleton Using `.instance` Only

Never call new — it will raise an error if you're using the Singleton module.

# ✅ Correct
    AppLogger.instance
    
    # ❌ Will raise NoMethodError
    AppLogger.new

5️⃣ Add a Shortcut (Optional)

Use a global method (defined in an initializer) for easier access.

# config/initializers/app_logger.rb
    def AppLog
      AppLogger.instance
    end
    
    # Now you can call:
    AppLog.log("Checkout completed")

6️⃣ Make It Testable

Mock or stub methods on the singleton object directly in tests.

allow(AppLogger.instance).to receive(:log).and_return(true)

7️⃣ Use with Services or Background Jobs, Not Controllers

Keep Singleton usage in service objects or job processors to keep controllers thin and clean.

# ✅ Good in a job or service
    AppLogger.instance.log("Job finished")

8️⃣ Document Its Purpose

Clearly comment on why you made the class a singleton to avoid misuse later.

# Singleton to ensure centralized logging
    class AppLogger
      include Singleton
    end

🧠 Summary

• ✅ Use Singleton module
• ✅ Keep it stateless when possible
• ✅ Use for global, shared services only
• ✅ Avoid overusing Singleton for objects that should be created fresh
• ✅ Write tests using .instance

🌍 Real-World Use Case

• Logger: One instance of a logger to write app logs.
• Config Manager: Centralized environment config loader.
• Metrics Collector: Collect app performance data globally.

🧠 Detailed Explanation – Observer Pattern (Simple)

The Observer Pattern is a way to tell other parts of your application when something has happened — like when a user signs up, an order is placed, or a post is published.

It works like a notification system. One object (called the subject) is being "watched" by other objects (called observers). When something changes in the subject, all its observers get notified automatically.

🔔 Simple Analogy

Imagine you press a doorbell. That one press sends signals to several places at once: a chime rings, a light flashes, and a camera starts recording. You didn’t have to tell each one — they all responded automatically. That’s what the observer pattern does in your app.

🛠 In Rails

In Rails, you can use the Observer pattern to run logic when something happens to a model — like a User or Order.

For example: when a user signs up, you might want to:

• Send a welcome email
• Log the signup for analytics
• Notify an admin

Instead of putting all that logic inside the User model, you put it in a separate class (an Observer) that listens for changes.

📌 Example Summary

• 👤 Subject: User model
• 👂 Observer: UserObserver
• 🎯 Event: after_create — user is created
• ⚡ Reaction: Send email, notify admin, log event

✅ Why Use It?

• ✅ Keeps your model clean and focused
• ✅ Makes your app easier to maintain and test
• ✅ Great for background jobs, analytics, and notifications

Bottom Line: The Observer Pattern helps your app respond automatically to model changes — without mixing logic inside your models.

📘 Key Terms & Concepts – Observer Pattern in Rails

🔁 Flow Section – How the Observer Pattern Works in Rails

The Observer Pattern follows a simple notification flow — when something happens to one object (the subject), it notifies another object (the observer) to take action. In Rails, this typically applies to model lifecycle events.

📊 Step-by-Step Flow

1. 1. A record is created or updated — for example, a new user signs up.
2. 2. The model triggers a lifecycle event — like after_create.
3. 3. An Observer class listens to that event — such as UserObserver.
4. 4. The Observer runs its method — like sending a welcome email or logging the event.

This flow keeps the logic clean and out of the model, making your app easier to scale and maintain.

🔁 Example Flow (User Signup)

• 🧍 User model = Subject
• 📬 UserObserver = Observer
• 🔁 Event = after_create
• ✅ Action = Send welcome email + notify admin

# app/models/user.rb
    class User < ApplicationRecord
      # No logic here — clean!
    end
    
    # app/observers/user_observer.rb
    class UserObserver < ActiveRecord::Observer
      def after_create(user)
        WelcomeMailer.send_email(user).deliver_later
        AdminNotifier.alert_new_user(user)
      end
    end

Enable it in your config:

config.active_record.observers = :user_observer

🏢 Where We Use the Observer Pattern in Rails

• 📧 Notifications: Send email/SMS on user signups or status changes
• 📦 E-commerce: Notify inventory or send invoice when an order is placed
• 📈 Analytics: Track user activity (like post views or signups)
• 📝 Auditing: Record model changes in a history log or change tracker
• 🧪 Testing: Trigger test environments when a deployment model updates
• 🔔 Third-party Integration: Notify Slack, Stripe, etc., when data changes

Tip: Use observers when you want to react to changes in your data, but don’t want to clutter the model itself with too much logic.

📦 Gems & Libraries Used – Observer Pattern in Rails

Rails removed built-in observer support in Rails 4, but you can still use it by adding a gem. Below are the main tools and libraries used for the Observer pattern:

Note: For standard Observer pattern support in Rails apps, start with rails-observers. For more flexible or async behavior, use wisper or ActiveSupport::Notifications.

🛠️ Best Implementation – Observer Pattern in Rails

To properly implement the Observer Pattern in Rails (Rails 4+), use the rails-observers gem. Below is the complete, detailed setup with a working example:

📦 Step 1: Add the Gem

Add the gem to your Gemfile:

# Gemfile
    gem 'rails-observers'

Then run:

bundle install

🏗️ Step 2: Generate or Create an Observer

Create an observer file for your model, e.g., UserObserver:

# app/observers/user_observer.rb
    class UserObserver < ActiveRecord::Observer
      def after_create(user)
        WelcomeMailer.send_email(user).deliver_later
        AdminNotifier.notify("New user signed up: #{user.email}")
      end
    end

This code triggers after a new user is created and performs two actions:

• ✅ Sends a welcome email
• ✅ Notifies admin via a custom service

⚙️ Step 3: Register the Observer

Edit your config/application.rb to register the observer:

# config/application.rb
    config.active_record.observers = :user_observer

Make sure to restart your Rails server after adding this line.

🧪 Step 4: Trigger the Event

Now, every time a User is created, the observer will be triggered:

User.create(email: "[email protected]", password: "password")

💡 You didn’t write any logic in the model — it all happens inside the observer.

✅ Step 5: Keep the Model Clean

Your model remains focused on validations and associations:

# app/models/user.rb
    class User < ApplicationRecord
      validates :email, presence: true
      has_secure_password
    end

👍 No side-effects like emails or notifications are handled inside the model.

🧠 Summary of Best Practices

• ✅ Use rails-observers gem in Rails 4+
• ✅ Put external side-effects (like emails, notifications) in observers
• ✅ Keep your model clean and focused only on data & validation
• ✅ Test observers separately as service layers
• ✅ Use deliver_later for async jobs (ActiveJob/Sidekiq)

💡 Examples – Observer Pattern in Rails

These examples show how the Observer Pattern helps organize logic outside the model for cleaner, maintainable Rails applications.

📧 Example 1: Send Welcome Email When User Signs Up

Scenario: When a user creates an account, send them a welcome email.

✅ Observer: UserObserver

# app/observers/user_observer.rb
    class UserObserver < ActiveRecord::Observer
      def after_create(user)
        WelcomeMailer.send_email(user).deliver_later
      end
    end

# app/mailers/welcome_mailer.rb
    class WelcomeMailer < ApplicationMailer
      def send_email(user)
        @user = user
        mail(to: @user.email, subject: "Welcome to our platform!")
      end
    end

🎯 When User.create is called, the mailer runs automatically without cluttering the model.

📦 Example 2: Notify Inventory After Order Is Placed

Scenario: When an order is created, notify the warehouse to prepare the package.

# app/observers/order_observer.rb
    class OrderObserver < ActiveRecord::Observer
      def after_create(order)
        InventoryService.notify(order.product_id, order.quantity)
      end
    end

✅ Keeps business logic out of the Order model and uses a clean service pattern.

📊 Example 3: Track Page View Analytics

Scenario: When a user visits a page, track the event for analytics.

# app/observers/page_view_observer.rb
    class PageViewObserver < ActiveRecord::Observer
      def after_create(view)
        AnalyticsService.track("page_visited", {
          page: view.page_name,
          user_id: view.user_id
        })
      end
    end

📈 Ideal for real-time dashboard metrics, keeping the tracking out of the controller/model logic.

🛡️ Example 4: Audit Trail on Record Updates

Scenario: Log every time a record is updated, for compliance/audit reasons.

# app/observers/user_observer.rb
    class UserObserver < ActiveRecord::Observer
      def after_update(user)
        AuditLog.create!(
          user_id: user.id,
          action: "update",
          changed_data: user.previous_changes
        )
      end
    end

📝 This creates an audit trail without cluttering your models with logging code.

✅ Summary of Real-World Usage

• 📧 Send emails (welcome, password reset, order confirmation)
• 📦 Notify inventory or shipping services
• 📊 Track events and analytics
• 🧾 Save audit logs for updates
• 🔔 Trigger background jobs or external APIs

🔁 Alternative Concepts

• Callbacks (built-in): Using after_create, before_save inside the model
• Service Objects: Custom classes that encapsulate logic triggered by model changes
• Event-Driven Pub/Sub: Use Redis or a pub/sub system for more complex workflows

💬 Technical Questions and Answers – Observer Pattern in Rails

class UserObserver < ActiveRecord::Observer
      def after_create(user)
        AdminNotifier.alert_new_signup(user)
      end
    end

# Gemfile
    gem 'rails-observers'
    
    # Then enable it
    config.active_record.observers = :user_observer

# ✅ Observer:
    class OrderObserver < ActiveRecord::Observer
      def after_create(order)
        Analytics.log("Order placed", order.id)
      end
    end

test "welcome email is sent after user creation" do
      user = User.new(email: "[email protected]")
      assert_difference 'ActionMailer::Base.deliveries.size', +1 do
        user.save
      end
    end

UserObserver
    OrderObserver
    InvoiceObserver

# Using a service object instead of an observer
    class OrderPlacement
      def self.call(order)
        OrderMailer.confirmation(order).deliver_later
        Analytics.track("order_created", order.id)
      end
    end

✅ Best Practices – Observer Pattern in Rails

Use the Observer Pattern in a clean, focused way to maintain readable, testable, and scalable Rails applications. Below are the most important practices with examples:

1️⃣ Keep Observers Focused on a Single Concern

Each observer should handle one type of logic — like sending emails, logging, or triggering jobs.

# GOOD: only sends emails
    class UserObserver < ActiveRecord::Observer
      def after_create(user)
        WelcomeMailer.send_email(user).deliver_later
      end
    end

# AVOID: mixing too many responsibilities
    def after_create(user)
      WelcomeMailer.send_email(user).deliver_later
      AuditLog.log_signup(user)
      Analytics.track("new_user", user.email)
    end

2️⃣ Avoid Business Logic in Observers

Observers should only react to events, not make decisions. Move business rules to service objects.

# GOOD
    def after_create(order)
      OrderNotifier.send_confirmation(order)
    end

# BAD
    def after_create(order)
      if order.amount > 1000
        PremiumMailer.send_discount(order)
      end
    end

3️⃣ Use deliver_later for Background Jobs

Send emails or external API calls asynchronously to avoid slowing down model creation.

AdminMailer.new_user_alert(user).deliver_later

4️⃣ Always Register Observers in application.rb

# config/application.rb
    config.active_record.observers = :user_observer

✅ Don’t forget to restart the server after registering!

5️⃣ Use Proper Naming

Match observer class names to the model name with Observer suffix.

class UserObserver < ActiveRecord::Observer

❌ Don’t use vague names like NotificationObserver unless it applies to multiple models and is intentionally generic.

6️⃣ Test Observers Separately

Write unit tests for each observer to confirm behavior works as expected:

test "observer sends welcome email" do
      assert_difference 'ActionMailer::Base.deliveries.size', 1 do
        User.create(email: "[email protected]", password: "secret123")
      end
    end

7️⃣ Avoid Multiple Observers for the Same Model

Too many observers on a single model can cause hard-to-track bugs. Combine related logic into a single observer where reasonable.

8️⃣ Use Alternatives for Complex Workflows

If you need more flexibility, consider event-based tools like:

• ActiveSupport::Notifications
• wisper
• Service Objects

# Alternative example with service object
    UserSignup.call(user: user)

🧠 Summary

• ✅ One observer = one job (email, logging, etc.)
• ✅ Avoid business logic inside observers
• ✅ Test each observer and keep them small
• ✅ Prefer deliver_later for async tasks
• ✅ Use observers for side effects, not data validation or rules

🌍 Real-World Use Case

• 🛒 E-commerce: After an Order is created, notify warehouse and customer
• 📧 User system: After user signs up, send welcome email and log the action
• 📊 Analytics: After a page is visited, trigger background job to log event

🧠 Detailed Explanation – Strategy Pattern (Simple)

The Strategy Pattern is a way to organize your code when you have multiple ways to do something — and you want to switch between them easily.

Instead of writing a lot of if or case statements in your code, you create small, focused classes — each one handling a specific way of doing the job.

You then pass the correct strategy (class) to your main object, and it uses that class to do the work. This makes your code:

• ✅ Clean
• ✅ Easy to test
• ✅ Easy to add new behaviors

🔔 Real-Life Analogy

Think of a payment process at a store. The cashier asks: "How do you want to pay?"

• 💳 Card
• 💵 Cash
• 📱 Mobile Payment

No matter what you choose, the cashier knows how to handle it — each method follows the same idea: "Pay".

🛠 In Rails

Let’s say you have different payment methods in your app. Instead of writing:

if method == "stripe"
      StripeService.new(order).charge
    elsif method == "paypal"
      PaypalService.new(order).charge
    end

❌ This grows fast and is hard to maintain.

✅ Instead, use the Strategy Pattern:

# Common interface
    class PaymentStrategy
      def initialize(strategy)
        @strategy = strategy
      end
    
      def pay(order)
        @strategy.pay(order)
      end
    end
    
    # Strategy 1
    class StripePayment
      def pay(order)
        puts "Paying #{order.total} with Stripe"
      end
    end
    
    # Strategy 2
    class CashPayment
      def pay(order)
        puts "Paying #{order.total} with Cash"
      end
    end
    
    # Usage
    payment = PaymentStrategy.new(StripePayment.new)
    payment.pay(order)

✅ Benefits

• 🚫 No more huge if/case blocks
• 🧪 Each strategy is easy to test alone
• ➕ Add a new payment method without touching existing ones

Bottom line: Strategy Pattern helps you switch behaviors cleanly, keep your code organized, and follow good software design principles like SOLID.

📘 Key Terms & Concepts – Strategy Pattern in Rails

🔁 Flow Section – How the Strategy Pattern Works in Rails

The Strategy Pattern allows you to define multiple ways of doing something — and then choose the correct way at runtime by passing in the right strategy.

This is useful when you have different behaviors (algorithms) that change based on the context — like payment methods, shipping rules, or tax calculations.

🔄 Step-by-Step Flow

1. 1. Define a common interface — e.g. pay(order) or calculate(order)
2. 2. Create separate classes for each behavior (e.g., StripePayment, CashPayment)
3. 3. Pass the strategy into a context class (e.g., PaymentStrategy)
4. 4. The context calls the method on the chosen strategy
5. 5. Each strategy performs its task differently but returns consistent output

💳 Example: Payment Strategy

Three different payment methods, all use the same method name: pay(order)

class StripePayment
      def pay(order)
        puts "Charged #{order.total} via Stripe"
      end
    end
    
    class CashPayment
      def pay(order)
        puts "Collected #{order.total} in cash"
      end
    end
    
    class PaymentStrategy
      def initialize(strategy)
        @strategy = strategy
      end
    
      def pay(order)
        @strategy.pay(order)
      end
    end
    
    # Usage
    strategy = PaymentStrategy.new(CashPayment.new)
    strategy.pay(order)

🏢 Where You Use Strategy Pattern in Rails

• 💳 Payments: Stripe, PayPal, Cash, Wallet
• 🏷️ Discount Rules: Percentage, fixed amount, first-time user
• 📦 Shipping Cost: Flat rate, per item, by region
• 📊 Analytics Reporting: Daily, weekly, monthly formats
• 🎯 Recommendation Engines: Personalized, trending, or rule-based
• 🔐 Authentication: Devise, OAuth, SAML, JWT — handled via interchangeable auth providers

Summary: Strategy Pattern is perfect when you need to support different behaviors with clean, swappable logic — especially when if/case statements would get messy.

📦 Gems & Libraries Used – Strategy Pattern in Rails

Ruby and Rails don’t require any special gems to use the Strategy Pattern — it can be implemented using plain Ruby classes and duck typing. However, some libraries help you organize, inject, or manage strategies more cleanly:

Tip: For most Rails apps, you can write Strategy classes manually without any gem. Use dry-rb or Trailblazer if your architecture grows more complex.

🛠️ Best Implementation – Strategy Pattern in Rails

Use Case: You want to apply different discount rules depending on the type of customer or promotion: percentage-based, fixed-amount, or tiered discount.

📁 1. Directory Structure

    app/
    └── strategies/
        ├── discount_strategy.rb
        ├── percentage_discount.rb
        ├── fixed_discount.rb
        └── tiered_discount.rb
      

📌 2. Base Interface – `DiscountStrategy`

This class defines the interface all strategies must follow:

# app/strategies/discount_strategy.rb
    class DiscountStrategy
      def apply(order)
        raise NotImplementedError, "Subclasses must implement `apply`"
      end
    end
      

💸 3. Implement Discount Strategies

# app/strategies/percentage_discount.rb
    class PercentageDiscount < DiscountStrategy
      def apply(order)
        order.total * 0.9  # 10% off
      end
    end
    
    # app/strategies/fixed_discount.rb
    class FixedDiscount < DiscountStrategy
      def apply(order)
        [order.total - 20, 0].max
      end
    end
    
    # app/strategies/tiered_discount.rb
    class TieredDiscount < DiscountStrategy
      def apply(order)
        if order.total > 300
          order.total * 0.8
        elsif order.total > 100
          order.total * 0.9
        else
          order.total
        end
      end
    end
      

📦 4. Context Class – `DiscountService`

This service receives the strategy and calls `apply`:

# app/services/discount_service.rb
    class DiscountService
      def initialize(strategy)
        @strategy = strategy
      end
    
      def apply_discount(order)
        @strategy.apply(order)
      end
    end
      

🚀 5. Usage in Controller or Model

# Example in controller or background job
    
    order = Order.find(params[:id])
    
    strategy =
      case current_user.tier
      when "premium"
        PercentageDiscount.new
      when "vip"
        TieredDiscount.new
      else
        FixedDiscount.new
      end
    
    final_total = DiscountService.new(strategy).apply_discount(order)
    order.update(total: final_total)
      

✅ Benefits of This Implementation

• 🎯 Clean separation of behaviors – each class handles one discount type.
• 🔁 Easily swappable logic – no big `if-else` blocks.
• 🧪 Simple testing – test each strategy class in isolation.
• ➕ Open for new strategies – just add a new class without modifying the others.

Note: You can register strategies using `dry-container` if you want to inject them dynamically from configuration.

💡 Examples in Detail – Strategy Pattern in Rails

Let’s walk through how different discount strategies work in real scenarios. Each example shows:

• 🎯 The user type or condition
• 🛍️ The order total
• ⚙️ The strategy applied
• 💰 Final total after discount

🧾 Example 1 – Premium User (10% off)

order = Order.new(total: 200)
    strategy = PercentageDiscount.new
    service = DiscountService.new(strategy)
    final_total = service.apply_discount(order)
    puts final_total  # => 180.0
      

Explanation: 10% of $200 = $20 discount. Final price = $180

🧾 Example 2 – VIP User (Tiered Discount)

order = Order.new(total: 350)
    strategy = TieredDiscount.new
    service = DiscountService.new(strategy)
    final_total = service.apply_discount(order)
    puts final_total  # => 280.0
      

Explanation: Order is over $300 → 20% off = $70. Final price = $280

🧾 Example 3 – Guest User (Fixed Discount)

order = Order.new(total: 50)
    strategy = FixedDiscount.new
    service = DiscountService.new(strategy)
    final_total = service.apply_discount(order)
    puts final_total  # => 30.0
      

Explanation: Fixed $20 discount on $50 → Final price = $30

🧾 Example 4 – Edge Case (Fixed Discount Lower Than Total)

order = Order.new(total: 15)
    strategy = FixedDiscount.new
    service = DiscountService.new(strategy)
    final_total = service.apply_discount(order)
    puts final_total  # => 0
      

Explanation: Discount is capped at order total. No negative prices allowed.

📌 Summary

• 👤 Choose strategy based on user or order type
• 🧩 Each strategy class handles its logic
• 🧼 Keeps your controller or service clean
• ✅ Easy to add more logic like coupons, limits, conditions

🔁 Alternative Concepts

• Case statements: Often replaced by Strategy to avoid complex conditionals
• Polymorphism: You can use inheritance or duck typing instead of explicitly setting strategy classes
• Service Objects: Can be used in tandem to keep strategy logic clean and testable

💬 Technical Questions & Answers – Strategy Pattern in Rails

🔹 Q1: What is the Strategy Pattern?

Answer: The Strategy Pattern defines a family of algorithms, encapsulates each one, and makes them interchangeable. It lets the algorithm vary independently from clients that use it.

✅ Example:

# Different payment types with same interface
    class PayPal
      def pay(order); puts "PayPal: #{order.total}"; end
    end
    
    class Stripe
      def pay(order); puts "Stripe: #{order.total}"; end
    end
      

🔹 Q2: Why use the Strategy Pattern instead of if/else logic?

Answer: It avoids large conditionals and keeps each behavior isolated, making the code cleaner, testable, and easier to extend.

🛑 Bad:

if type == "paypal"
      pay_with_paypal(order)
    elsif type == "stripe"
      pay_with_stripe(order)
    end

✅ Good (Strategy):

strategy = Stripe.new
    strategy.pay(order)

🔹 Q3: How do you implement the Strategy Pattern in Rails?

Answer: You create a base interface, define multiple strategy classes, and inject the strategy into a context object or service.

🧪 Example:

class DiscountService
      def initialize(strategy)
        @strategy = strategy
      end
    
      def apply(order)
        @strategy.apply(order)
      end
    end

🔹 Q4: How does the Strategy Pattern support the Open/Closed Principle?

Answer: It allows you to add new behaviors (strategies) without modifying existing logic — just create a new class that implements the same interface.

Example:

class LoyaltyDiscount
      def apply(order)
        order.total * 0.85
      end
    end

🔹 Q5: How can you dynamically choose a strategy at runtime in Rails?

Answer: Based on user role, plan, or params — instantiate the correct strategy and pass it into the service.

strategy =
      case current_user.tier
      when "vip" then TieredDiscount.new
      when "premium" then PercentageDiscount.new
      else FixedDiscount.new
      end

🔹 Q6: How do you test a Strategy class?

Answer: Isolate each strategy in its own spec file and verify it performs the correct behavior.

describe FixedDiscount do
      it "reduces total by 20" do
        order = double(total: 100)
        result = described_class.new.apply(order)
        expect(result).to eq(80)
      end
    end

✅ Best Practices – Strategy Pattern in Rails

🧩 1. Use a Common Interface

All strategy classes must respond to the same method (e.g., apply(order)), even if they implement it differently.

class DiscountStrategy
      def apply(order)
        raise NotImplementedError
      end
    end

🧼 2. Avoid Conditionals in Core Logic

Don’t use if/else or case inside service methods. Handle branching outside using strategy injection.

# ❌ Bad: branching inside the method
    def apply_discount(order)
      if user.vip?
        order.total * 0.8
      elsif user.premium?
        order.total * 0.9
      end
    end
    
    # ✅ Good: inject the correct behavior
    DiscountService.new(TieredDiscount.new).apply(order)

🔄 3. Let Strategies Be Reusable & Stateless

Strategy classes should not depend on instance variables or external state. Pass data through arguments.

class FixedDiscount
      def apply(order)
        [order.total - 20, 0].max
      end
    end

♻️ 4. Keep Strategy-Specific Logic Out of the Controller

Use a service or context object to delegate logic, so the controller only handles user input and rendering.

# ✅ Clean controller
    strategy = strategy_for(current_user)
    final_price = DiscountService.new(strategy).apply(order)

🧪 5. Unit Test Each Strategy Separately

Write small, focused specs for each strategy instead of testing the full pipeline repeatedly.

describe PercentageDiscount do
      it "applies 10% discount" do
        order = OpenStruct.new(total: 100)
        expect(described_class.new.apply(order)).to eq(90)
      end
    end

➕ 6. Extend Easily by Adding New Strategy Classes

When a new use case arises (e.g. seasonal discounts), just add a new class. No need to touch old code.

class SeasonalDiscount
      def apply(order)
        order.total * 0.75
      end
    end

📦 7. Optional: Use `dry-container` to Register Strategies

For advanced systems, you can auto-register strategies and resolve them based on keys.

# Register in container
    MyContainer.register(:vip_discount, TieredDiscount.new)
    # Resolve
    MyContainer.resolve(:vip_discount).apply(order)

📌 Summary Table

🌍 Real-World Use Cases in Rails

• 💳 Payments: Stripe, PayPal, bank transfer, cash-on-delivery
• 🏷️ Discounts: Apply different rules for percentage, fixed, or tier-based discounts
• 📦 Shipping: Choose between shipping providers like FedEx, UPS, DHL
• 🔐 Authentication: Use different strategies (Devise, OAuth, JWT)
• 🧠 Recommendation Engines: Swap between trending, personalized, or AI-driven strategies

🧠 Easy Explanation

The Adapter Pattern helps connect two systems or classes that were not designed to work together. Think of it like a power plug adapter – your laptop has a US-style plug, but the wall outlet in Europe is different. Instead of replacing your laptop or the wall, you use an adapter to make them connect.

In Ruby on Rails, you often deal with third-party APIs (like Stripe, PayPal, Twilio) or legacy systems that don’t match your app's expected method names. The Adapter Pattern lets you write a small “translator” class that converts your app’s method calls into the format the external system understands.

🔧 Example Use Case

• You have a new PaymentProcessor interface in your app: .pay(amount)
• You want to reuse an old library that only has .send_payment(sum)
• You write an Adapter class that calls .send_payment when your app calls .pay

🔄 What It Solves

• ✔ Keeps your code consistent even when external interfaces are different
• ✔ Avoids rewriting or modifying external or legacy code
• ✔ Keeps your business logic clean and isolated

📌 Summary

Adapter Pattern = Translator between incompatible objects. It lets you use new or legacy code without rewriting the rest of your app.

📚 Terms & Concepts – Adapter Pattern

🔁 Flow: How the Adapter Pattern Works

1. You define a standard interface that your app will call (e.g., pay(amount)).
2. You have a third-party or legacy class with a different interface (e.g., send_payment(sum)).
3. You create an Adapter class that implements your standard interface but internally calls the legacy method.
4. Your app code uses the adapter instead of directly using the third-party or legacy code.

# 👇 Your expected interface
    class PaymentGateway
      def pay(amount); end
    end
    
    # 👇 External legacy code
    class LegacyPay
      def send_payment(sum)
        puts "Sent payment of #{sum}"
      end
    end
    
    # 👇 Adapter connects them
    class LegacyPayAdapter < PaymentGateway
      def initialize(legacy)
        @legacy = legacy
      end
    
      def pay(amount)
        @legacy.send_payment(amount)
      end
    end

📌 Where It’s Commonly Used in Rails Projects

• 💳 Payment Gateways: Adapting different payment service providers (e.g., PayPal, Stripe, Razorpay).
• 📩 Messaging APIs: Integrating SMS/WhatsApp/Email APIs with different method structures.
• 🔌 External APIs: When APIs return unexpected field formats or naming (e.g., `userId` vs `id`).
• 🧾 Legacy Systems: Reusing old business logic with new Rails controllers or services.
• 🧪 Testing Mocks: Providing fake adapters in test environments that behave like real ones.

Instead of rewriting old logic or forcing your app to fit external systems, you build a small adapter to do the translation. It's fast, safe, and scalable.

📦 Gems & Libraries – Adapter Pattern

The Adapter Pattern itself doesn’t require a specific gem, but in complex systems or integrations, the following gems help you **implement it cleanly**, especially with external services:

📝 Example Setup with `dry-container`

# Define the container
    class Container
      extend Dry::Container::Mixin
    end
    
    # Register adapters
    Container.register("payment.stripe", StripeAdapter.new)
    Container.register("payment.legacy", LegacyPayAdapter.new)
    
    # Resolve
    Container.resolve("payment.stripe").pay(100)

These libraries let you apply the Adapter Pattern in a clean, maintainable, and testable way – especially useful in service-oriented Rails apps.

🧱 Best Implementation – Step-by-Step in Rails

This example demonstrates how to integrate a legacy class (LegacyPay) into your Rails service layer by using an adapter that matches your app’s standard interface (PaymentGateway).

🎯 Step 1: Define the Expected Interface

This is the consistent interface your app expects every payment system to follow.

# app/interfaces/payment_gateway.rb
    module PaymentGateway
      def pay(amount)
        raise NotImplementedError, "Must implement #pay"
      end
    end
      

💳 Step 2: External/Legacy Class

This is an existing library you cannot modify. It has a different method name or signature.

# lib/legacy_pay.rb
    class LegacyPay
      def send_payment(sum)
        "Processed legacy payment of #{sum}"
      end
    end
      

🔄 Step 3: Create the Adapter

This adapter wraps the legacy class and implements the expected interface using composition.

# app/adapters/legacy_pay_adapter.rb
    class LegacyPayAdapter
      include PaymentGateway
    
      def initialize(legacy = LegacyPay.new)
        @legacy = legacy
      end
    
      def pay(amount)
        @legacy.send_payment(amount)
      end
    end
      

🧪 Step 4: Use It in a Service

Now your main business logic can remain clean and work with any payment method using the standard interface.

# app/services/payment_service.rb
    class PaymentService
      def initialize(gateway:)
        @gateway = gateway
      end
    
      def execute(amount)
        @gateway.pay(amount)
      end
    end
    
    # Usage
    service = PaymentService.new(gateway: LegacyPayAdapter.new)
    puts service.execute(200)  # => "Processed legacy payment of 200"
      

📌 Benefits of This Structure

• ✅ Keeps your service layer decoupled from third-party or legacy logic
• ✅ Makes testing easy – you can stub adapters
• ✅ Easy to swap adapters in the future (e.g., switch from legacy to Stripe)
• ✅ Follows Open/Closed Principle (you’re adding new behavior without modifying existing code)

🧪 Testing Tip

# spec/adapters/legacy_pay_adapter_spec.rb
    it "adapts legacy method to new pay interface" do
      legacy = instance_double("LegacyPay", send_payment: "ok")
      adapter = LegacyPayAdapter.new(legacy)
    
      expect(adapter.pay(100)).to eq("ok")
    end
      

💡 Example

# Old payment gateway
class LegacyPayment
  def pay_money(amount)
    "Paid #{amount}"
  end
end

# Adapter
class PaymentAdapter
  def initialize(legacy_payment)
    @legacy_payment = legacy_payment
  end

  def pay(amount)
    @legacy_payment.pay_money(amount)
  end
end

# Usage
PaymentAdapter.new(LegacyPayment.new).pay(100)

🔁 Alternatives

• Decorator Pattern (for extending behavior)
• Strategy Pattern (for interchangeable logic)
• Facade Pattern (to simplify complex interfaces)

💬 Technical Q&A – Adapter Pattern

# Adapter translates legacy.send_payment to app.pay
    class LegacyPayAdapter
      def initialize(legacy = LegacyPay.new)
        @legacy = legacy
      end
    
      def pay(amount)
        @legacy.send_payment(amount)
      end
    end

module PaymentGateway
      def pay(amount)
        raise NotImplementedError
      end
    end
    
    class LegacyPayAdapter
      include PaymentGateway
    
      def pay(amount)
        LegacyPay.new.send_payment(amount)
      end
    end

it "forwards call from pay to send_payment" do
      legacy = instance_double("LegacyPay")
      expect(legacy).to receive(:send_payment).with(100)
      LegacyPayAdapter.new(legacy).pay(100)
    end

✅ Best Practices – Adapter Pattern

• ✅ 1. Use Interfaces or Modules to Define Expectations
  Define a consistent interface your app expects so all adapters follow a contract.

  # app/interfaces/payment_gateway.rb
      module PaymentGateway
        def pay(amount)
          raise NotImplementedError
        end
      end

• ✅ 2. Use Composition, Not Inheritance
  Instead of subclassing the adaptee, use composition inside your adapter.

  class LegacyPayAdapter
        def initialize(legacy = LegacyPay.new)
          @legacy = legacy
        end
      
        def pay(amount)
          @legacy.send_payment(amount)
        end
      end

• ✅ 3. Keep Adapter Classes Focused
  Adapters should only handle method translation—not business logic or validations.
• ✅ 4. Name Adapters Clearly
  Use the pattern [Service]Adapter or [External]Wrapper for clarity.
  • StripeAdapter, LegacyPayAdapter, TwilioSMSAdapter
• ✅ 5. Use Dependency Injection for Flexibility
  Inject adapters into services instead of hardcoding them for easier testing and swapping.

  class PaymentService
        def initialize(gateway:)
          @gateway = gateway
        end
      
        def execute(amount)
          @gateway.pay(amount)
        end
      end

• ✅ 6. Write Unit Tests for Adapters
  Test that your adapter correctly maps the interface to the adaptee's method.

  it "adapts pay to send_payment" do
        legacy = instance_double("LegacyPay", send_payment: "done")
        adapter = LegacyPayAdapter.new(legacy)
      
        expect(adapter.pay(100)).to eq("done")
      end

• ✅ 7. Avoid Adapter Chains
  Don’t stack multiple adapters. If you need more, extract them into service objects.

Tip: You can use adapters as plug-and-play strategy classes for different APIs (Stripe, PayPal, Razorpay), making your code future-proof and easier to maintain.

🌍 Real-World Use Case

Using the Adapter Pattern to make a legacy billing system work with a new payment interface in a Rails ecommerce app.

🔍 What is the Template Method Pattern?

The Template Method Pattern defines a fixed step-by-step algorithm in a base class, but allows subclasses to customize specific steps. Think of it like a recipe: the overall steps are the same, but you can tweak the ingredients in your own way.

🍰 Real-World Analogy

Imagine you're baking a cake:

• 1. Prepare ingredients
• 2. Mix them
• 3. Bake
• 4. Decorate

🛠️ Why Use It in Rails?

• ✅ You want consistent structure across multiple classes.
• ✅ You want child classes to override specific logic.
• ✅ You want to enforce a workflow (like exporting reports or processing files).

⚙️ How It Works in Code

In Ruby, you define a method like process that calls several internal methods (like fetch, parse, save), and you leave those steps for subclasses to define.

class ImportService
      def process
        read_file
        parse_data
        store_data
      end
    
      def read_file
        raise NotImplementedError
      end
    
      def parse_data
        raise NotImplementedError
      end
    
      def store_data
        puts "Saving to database..."
      end
    end
    
    class CSVImport < ImportService
      def read_file
        puts "Reading CSV..."
      end
    
      def parse_data
        puts "Parsing CSV rows..."
      end
    end
    
    CSVImport.new.process
    # Output:
    # Reading CSV...
    # Parsing CSV rows...
    # Saving to database...

🚀 Summary

Template Method Pattern is perfect when:

• You want to avoid code duplication across similar classes.
• You want to enforce a workflow but still keep it flexible.
• You build systems with multiple subclasses that follow similar steps (like exporters, processors, importers).

📚 Key Terms & Concepts