Use concerns to keep your models manageable

gistfile1.rb

# autoload concerns
module YourApp
  class Application < Rails::Application
    config.autoload_paths += %W(
      #{config.root}/app/controllers/concerns
      #{config.root}/app/models/concerns
    )
  end
end

# app/models/concerns/trashable.rb
module Trashable
  extend ActiveSupport::Concern
  
  included do
    default_scope   where(trashed: false)
    scope :trashed, where(trashed: true)
  end
  
  def trash
    update_attribute :trashed, true
  end
end

# app/models/message.rb
class Message < ActiveRecord::Base
  include Trashable, Subscribable, Commentable, Eventable
end

Instead of the autoload paths:

  #{config.root}/app/controllers/concerns
  #{config.root}/app/models/concerns

Does anybody have any reasons (stylistic or practical) as to why not use

# app/models/concerns/trashable.rb
module Concerns::Trashable

Maybe it looks better than having to repeat the module for each concern?

  include Concerns::Trashable, Concerns::Subscribable, Concerns::Commentable, Concerns::Eventable

I think the given that Rails4 will have those paths autoloaded, it makes more sense to not namespace those paths, and thus not use Concerns::.

@justin808
I think you can create a folder called shared for all shared modules
So that you have to include Shared::Trashable in app/models/concerns/shared/trashable.rb, not just Trashable
Also if you got both Message::Trashable and Shared::Trashable, you won't be confused on which to include

I recently saw this article as a counterpoint to this approach to breaking down model classes:

http://blog.codeclimate.com/blog/2012/10/17/7-ways-to-decompose-fat-activerecord-models/

Great, I also found few more ways to keep your code modular - http://amolnpujari.wordpress.com/2013/04/09/184/

concerns sucks compared to DCI. I hope ruby community will improve ruby to support DCI (extend/unextend modules on instances). Roles >>> concerns. Because roles are limited to contexts and you can't write spaghetti code, when you use method from role that should not be involved in current context. It is clear signal to developer - that something went wrong, architecture should be improved. In case of concerns you put everything in one object and let mess and spaghetti code happen in contexts (in Rails case in controllers or other "services" modules used by controllers).

DCI sample

https://gist.github.com/izbor/4ae08b0b57e9a810a852

@IZBOR besides the fact that this discussion has nothing to do with DCI, DCI is slow and is not really spreading a ton because of that.

Great article from codeclimate on making fat model thin http://blog.codeclimate.com/blog/2012/10/17/7-ways-to-decompose-fat-activerecord-models/