i’m preparing a talk for either railsconf or railsworld that puts this question/concern to the community. two times i have deviated from the standard apps/{models,controllers,views} layout and i have profited massively, especially in terms of conceptual integrity and abstraction. all my code lives in app/lib under domain-specific directories. this includes the models. the only part worth separating is the web router and controllers. i have achieved separation between my app and the web parts that aren’t offered by default by rails. i’m hoping to share my experience, for the community’s consideration.
I've had the pleasure to work on such kinds of Rails apps a few times. It was almost magical, compared to all the other common Rails apps with their ever accumulating fat models, complex controllers, untestable- coupled classes and so on.
One had this what you describe: everything in /lib, and the MVC merely delegating to that. MVC downgraded to what it should be: plumbing that binds together your domain stuff.
The other did something similar but had it in gems (bound as Railties/engines). IT was a bit more cumbersome, as one had to release a new gem before being able to integrate it in the rails app. It forced a very solid separation of concerns.
> compared to all the other common Rails apps with their ever accumulating fat models, complex controllers
i interpret fat model as: what can be move to the model, sits better in the model (directory). things that cannot be moved to the model: the request, the response, the session. not set in stone, but usually this works.
what i regret about older Rails code i wrote was the gluing of all biz logic to ActiveRecord ORM models (akin to, yuck, Hibernate entities), that also contain DOAs, form validation and all business logic. now i tend to split these out: form dtos that do validation, repos with queries, simple record classes, etc.
fat signals homogenous big thing, but is actually where most of the application lives. i coudl call it lib as well.
Except that Models are also Records. So by definition they don't separate concerns: for one the separation of concerns between "storing/retrieving stuff"
and "all the business logic stuff".
This lack or SoC, invites other tight coupling: For example, in Rails we commonly couple our models to our database design. You need a Medicine Adjustment? Better have a "medicine_adjustments" table, eventhough its more an Event than a record. Sure, you can pick and choose pieces of ActiveModel, and build models that aren't backed by database-tables, or by multiple tables. I do that all the time. But its far easier to just tightly model each Model around a Record/db-table. And because it's easier, its what most of us (especially juniors not bitten by it years later) will do: the easy way.
In the book "Growing Rails Applications"¹ has the -IMO- best practical patterns to solve this, but it goes right against the "you open a rails app and know what's happening": neat patterns, well manageable, and well documented, but very non-railsy.
i doubt. the further down the wedge drives the harder it gets to make the components communicate, and i think when communication gets hard we’ve probably gone too far. that’s not even taking into consideration the mechanisms of managing engines/gems.
