Many consider concerns usage a good practice for Rails applications development. Others try to avoid them as much as possible. In this post we'll try to add some clarity on this controversial topic.

1. Puts the following code into controllers → concerns → application_shape.rb:

module ApplicationShape
  extend ActiveSupport::Concern

  module ClassMethods
    delegate :model_name, to: :superclass
    delegate :name, to: :superclass
  end
end

Business logic consists of business domain description and business operations.

Business domain description - a set of domain models and their relations. Business operations (use cases, scenarios) - the logic of how we create, destroy and modify stuff...

Four years have passed since I drew this picture. It feels like it didn't change quite a lot since then.

I was preparing my talk for RubyC-2018 and came up with the following diagram to describe the evolution of mindset of a regular Rails developer...

In short:

• Rails is not evolving
• Hanami is not a panacea
• There is no common Rails Way 2.0 or anything like this
• Finding the golden mean between Rails way and Java way is hard
• …But doable!

Although this picture was drawn more than a year ago, the situation is still more or less the same.

Current state of ruby on rails community. //cc @adman65 @avdi @andrzejkrzywda @_solnic_ pic.twitter.com/1WUJS6c7Yy

— Ivan Nemytchenko (@inemation)...

Ruby on Rails is considered a universal framework for web application creation. So, whenever you develop something for the web with Ruby, Rails is your choice by default.

At the beginning of development, everything is super quick and straightforward...

Let's suppose for now that maybe we don't completely understand something. This little something makes us use Rails in the wrong way.

In the early days, we accepted a few principles unconditionally because they sounded like axioms. Here are some of...