The following is a list of some of the kinds of component that can be included in a three-tier architecture Rails application.

Rails includes more than just models, views, and controllers. The main difference here is that Rails doesn’t have an application tier in between the presentation and data tiers: controllers call models directly, and business logic lives in one or the other of those. This is fine for smaller applications, but for larger ones an additional layer can be helpful. Not every application needs all of these types of components; each should be added only when a specific application’s needs warrant it.

This list adds components in all three tiers following different design patterns. Components built-in to Rails are listed in bold.

Presentation Tier

Web Application

• HTML View: ERB
• Controller: ActionController
• Presenter: gets some display logic out of the view and the controller - PORO (video)
• Decorator: takes the place of helpers, providing display logic in an object-oriented way - Draper
• Form Object: for when a form maps to multiple models; can have form-specific validations - ActiveModel::Validations

Web API

• Controller - ActionController
• Serializer: gets JSON mapping out of the model - ActiveModel::Serializers
• JSON-API: exposes models as a JSON-API without having to custom-code routes and controllers - JSONAPI::Resources

Command Line

• Command Line Task: Rake

Application Tier

• Queued Job: ActiveJob
• Event: ActiveSupport::Notifications (video intro)
• Service Object: business logic accessible from multiple presentations - PORO; one speaker recommends using ActiveJob for these
• Domain Model: PORO

Data Tier

• Model: ActiveRecord
• Concern: groups related or reusable model functionality into a separate module
• Repository: PORO using ActiveRecord