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

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. https://rubyandrails.info/books/growing-rails-applications-in-practice https://rubyandrails.info/books/growing-rails-applications-i...