I really liked the tone of this post.<p>It presented an argument, offered alternative viewpoints, and articulated why the author thinks his approach is better than alternatives (without overly attacking them). Code samples were provided with real-life examples.<p>Whether or not I side with Concerns or DCI or something else, I got value out of reading this post and my understanding of Concerns improved.<p>This is a welcome relief to what was becoming a tense and drama-filled debate (Rails OOP design). Nice work, dhh.
This is my favorite part of the piece:
"I far prefer current_account.posts.visible_to(current_user) to involving a third query object."<p>I couldn't agree more.<p>People treating the single responsibility principle as the holy grail keep advocating an object for everything. In more complex cases, you may need an object for something, but not in every case. In those simpler cases, I think something like what DHH's example advocates is more appropriate.
Can anyone 'splain, using little words, or refer me to a 'splanation of just enough Rails info to follow this article?<p>(Highly amused formerly chubby gal who felt fine about her body back in the day and got drawn into reading this piece by the ridiculous "sexist!" accusations -- highly amused because this stupid stuff might lead me down the slippery slope to actually begin learning to program. Thus any cooperation is much appreciated. Mmkay? Thanks!)
I don't agree with equating cross cutting concerns with the purpose of "roles" in DCI. These are not mutually exclusive ideas. DCI is seems almost exclusively concerned with changes in domain state. That is, organizing the interactions between actors in the domain model into contexts which, generally speaking, result in changes in state.<p>I find, DCI doesn't say much with regards to how you query that state or present it to the user. I don't need a context or role to query data. Concerns do seem to provide some really nice ways to "DRY" things up on that end.<p>Certainly you can use concerns to deal with interaction/role type issues, but then they really aren't all that "cross-cutting" they tend to be specific to a particular use case or scenario. In which case I think there are better options. DCI is one, domain services are another. But hey, if Concerns work as your golden hammer by all means. I have some doubts.<p>I don't see this as a DCI vs. Concerns argument. However, if you want to argue it isn't possible to do DCI well in Ruby (extend sucks, yadda, yadda, yadda) go right ahead.
Sorry but where are the chubby models? Maybe I misread, but it seems like this is an argument over many <i>small</i> models vs. using aspects.<p>A chubby model would be one that implemented its own versions of multiple cross-cutting concerns, no?<p>Great title though, very creative. And also a very good idea in practice.
Is this pretty much what you'd do in Django by using abstract base models as a mixin?<p>I've got an abstract model 'PageLike' that contains a bunch of fields common to all page-like concrete models (title, metadata, content, last modified etc)<p>Or is there something more going on here?