I’m still pretty new to Rails but I can tell you what I do.
I put all my business logic under app/models. I consider this the
root of my domain model. For domain modeling I’m a fan of the book
‘Domain Driven Design’ by Eric Evans. He provides a good taxonomy of
business objects. The main types I use in Rails apps are entities
(extend ActiveRecord::Base, have identity and map to a table), values
objects (aggregates), and policies (strategy or business rule classes
that entities and value objects delegate to). However Evans recommends
packaging the domain model based on natural divisions in the domain, not
technical divisions. So I might have something like this:
But not something like this:
app/models/entities # sales and inventory entities
app/models/valueobjects # sales and inventory value objects
app/models/policies # sales and inventory policies
I think the structure and layout of the domain model should reflect the
business domain, so I don’t like putting business objects under lib. I
reserve lib for technical utility type methods or extensions that might
be useful in other projects – the kind of stuff that Rails puts in
But to be honest though none of my Rails projects have been that big. I
started to create sub-directories under models like sales, inventory,
using Modules to split the names space. (Just like packages in Java.)
But I decided that for my project that was overkill and I yanked it out.
Coming from Java, I actually like the fact that you can put many classes
in one file in Ruby. It encourages you to create little classes.
Sometimes in Java I wouldn’t create a sub-class just because of the
psychological resistance to creating a new file. Or I’d create static
inner classes, which is a tad ugly.
But I agree standards can be good. I’m just glad that in Ruby they’re
not built into the language. That’s too inflexible!
I keep speaking of my Java experience in the past tense. I wish! Time
to get back to my day job, coding in Java!