[karmajunkie]

Fair enough—I was being a bit of an asshole. However, when you start your contribution to the thread by insinuating DHH is above reproach, I'm not filled with sympathy. Especially when his architectural hipsterism is IMHO responsible for ruining a couple microgenerations of developers who learned to code through rails.

I can't be the first guy who's put his head through a wall upon hearing you say persistence is part of the domain. The only time persistence is domain is when your domain is the data store. "But AR is the database"—totally correct. the domain of AR is the database. But that is almost never the same as your business domain, and trying to mix the two creates a great deal of incidental complexity.

[realntl]

To be fair, a great many of web apps can justifiably say "my domain is the data store." In fact, whenever I use BaseCamp, that's exactly what strikes me almost immediately. Stock rails tends to be a great fit in those cases; your business objects are bags of data. Of course, those projects don't happen to be all that interesting to work on technologically, but I wouldn't want to work on MS Access "apps," either.

[karmajunkie]

That's incidental isomorphism between the two, and its different from your domain being your data store. You're right, there's a great many apps that can get away with it for awhile. And for those apps that fit in that mold and just kind of stall out or never grow, more power to them. Any app that continues to grow in terms of features or scale WILL break out of that mold—unless they're tethered so tightly to it that it becomes an anchor (which, let's face it, is most rails apps in the wild.)

[dean]

AR is not just about persistence. AR is an object-relational mapping which maps an obect oriented object in your code, to a row in a relational database table. It is an adapter between two different ways of representing data. But don't forget that Objects are not just data, they are also behavior. They are your domain. The 'object' comes first and the 'relational' comes second. AR encapsulates your data and makes database access transparent, but it still represents your domain.

Martin Fowler's Catalog of Patterns: http://www.martinfowler.com/eaaCatalog/activeRecord.html

[davedx]

Yup. Hence "services", as soon as your domain starts to get complicated. You need an abstraction layer between your application flow control (controllers) and your persistence layer (AR, or whatever). At least, that's what I'm given to understand about this. Does that sound right?