ruby-on-railsrubyactiverecordmodelservice-object

Rails - Where (directories) to put Models that are not Active Record

We are building out apps that have Models that are not database components. We are curious to learn what others are doing in the rails community to address this subject.

We are struggling with where to put them.

Should we have:

app/models/domain

or

app/domain/models

or perhaps

app/models   # Business Models
app/models/ar # Active Record Models

or perhaps

app/models/domain/   # Business Models
app/models/domain/ar # Active Record Models

Part of this is that we are struggling with how close to be to rails standards and how much to create a structure that will be good for what we need.

If we think of the objects as Service Objects, we could have

app/models/service-object

and

app/models/ # For plain active record

Another route to go down is not have stuff within app, e.g.

/service_objects

instead of

/app/models/service_objects

Presumably if we want access via a rails app we're better of using app/ in order to take advantage of convention over configuration.

Solution

  • In my experience, the division of where you put these models comes down to what they functionally represent in the specific context of your application.

    I usually reserve app/models for resource based models. If that model represents a resource that is instantiated and manipulated by your application it goes here. Doesn't need to be AR or db backed.

    If the model serves a consistent functionality but varies on the parameters, I give them a top level dir in app. Such as app/mailers app/observers etc. However, if you have one resource that requires an observer, it might not make sense to have an app/observers dir with just one file in it.

    Everything else goes in lib. There are a few reasons why this is preferable.

    1. You can choose when to require the files in lib. You can be much more selective about which files get loaded when your app starts. If you put everything in app/models you've got no granularity over what gets loaded.

    2. Namespacing your models as your app grows is easier in lib. Sure you can namespace in app/models but several layers of nesting in app/models always ends up nasty. It's best to keep the namespacing in lib.

    3. Housekeeping is made much easier when you've got things in their functionally correct place. It's not a resource? It's not an observer? Must be in lib. The whole reason you're putting thought into this up front is to provide discoverability to developers down the line.