Please. I'm well aware of who the parent was. I'm well aware of what his intent was. And I'm well aware not only of the strengths of the active record pattern (which I implemented in at least two different languages five years before he put Rails out there—as did many, many others) but also its inherent weaknesses.
You keep using the term "domain model" to refer to active record objects, which makes it clear that you've bought into the Rails appropriation of the term. AR objects are not domain models. If they were, the persistence would be handled elsewhere. Compared to a real domain model, AR objects are just a short step above using a naked database driver itself (and not necessarily an improvement thereof.) So to answer your question ("why are you extending activerecord?") its because you're taking a shortcut to dumping data into your database, and failing to create a real domain model while you're at it. That's a path that works ok for plenty of apps—but you want to know why rails has a reputation as being great at prototypes and shitty at scaling complexity? Because ActiveRecord is shitty at scaling complexity, and that's a hell of a lot more relevant to the vast majority of applications than scaling performance.
"If they were, the persistence would be handled elsewhere."
Persistance is handled elsewhere, it's handled in the superclass. If you think that's not a good idea, you shouldn't be using ActiveRecord, because that's the way it works.
You could argue there's not enough abstraction from the DB in AR, but that's a different discussion. Here we discussed if the persistance callbacks were an appropriate tool for in the domain model, and I reckon they are.
Also, any fool knows that putting lots of code in a single file is not a good way of scaling complexity, so yeah at some point you're going to need to break your code out in concerns and what not. ActiveRecord most certainly does not stand in the way of that.
Jesus christ. You aren't seriously arguing that handling it in a parent class removes it from the AR object's responsibilities, are you? In point of fact, that inheritance pattern is a bad idea, and I don't use it when I'm implementing an actual domain model, but that's seriously irrelevant.
1) I did argue exactly that; 2) it follows from (1) that an evented mechanism based on the database lifecycle of such objects is about the persistence of said objects, not about the domain.
lastly, if you think code complexity is about how fat your models are, I urge you to get out of "the rails way" for awhile and do some heavy reading. Moving code into concerns is just geography, and having lots of code in a single class is merely the most visible symptom of complexity.
No. I was not arguing anything about it, but the fact that it is a proper abstraction.
The persistence is part of the domain. You need to know about when your objects are persisted and when they are not, this can be an intrinsic part of some of your business logic. Thus the events are relevant to your domain.
Of course not all your business logic needs to be aware of persistence, and nowhere do you see me arguing that all business logic should be in concerns included into the AR class.
Don't put words in my mouth, and don't assume I am stupid. You are arguing in a rather ad-hominem way, and it is diminutive to your arguments.
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.
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.
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.)
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.
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?
Concerns are just a complicated way of putting lots of code in a single class. The interface is the same if you put everything in the same file or if you break it out into a dozen mixins/concerns.
You keep using the term "domain model" to refer to active record objects, which makes it clear that you've bought into the Rails appropriation of the term. AR objects are not domain models. If they were, the persistence would be handled elsewhere. Compared to a real domain model, AR objects are just a short step above using a naked database driver itself (and not necessarily an improvement thereof.) So to answer your question ("why are you extending activerecord?") its because you're taking a shortcut to dumping data into your database, and failing to create a real domain model while you're at it. That's a path that works ok for plenty of apps—but you want to know why rails has a reputation as being great at prototypes and shitty at scaling complexity? Because ActiveRecord is shitty at scaling complexity, and that's a hell of a lot more relevant to the vast majority of applications than scaling performance.