Thanks for taking a look - I certainly respect your viewpoint.
I guess where we diverge is the amount of domain logic which lives on an ActiveRecord model.
My experience is relatively limited, but in 4 or so years of professional Rails development, across many different codebases, the overwhelming majority of problems have been caused by bloated models with too many responsibilities.
You clearly have more experience with Rails, but your solution always seems to be "If you were smarter, you wouldn't have these problems with my framework". I've seen this problem recur again and again across multiple teams & codebases.
We're seeking to address that problem with these concepts that have been successfully used in other frameworks & languages.
Yes, when stumbling across bad code, the first instinct should be: how can I make this simpler. Not how can I wrap this bad code in more convoluted patterns. Don't use a big word when a small one will do.
Additionally, I find that the key problem with bloated models stems from missing domain models (often has-many-through models). Not from moving the logic of the existing models into more noun classes. In your example here, the purpose of the ticket is to tie a user to a grouper: that's exactly the place to put logic that governs that connection!
Finally, what gets my goat is this notion that these patterns are necessitated by "advanced deployments". As it was some law of nature that when your app hits a certain size, you have to introduce this litany of misfit patterns. That's like arguing that if your book is longer than 300 pages, it must also use really big words and complex sentence structures. What?
The solution to large applications is to double down on simplicity, not give up on it. It is even more important to get the basics right. Execute them beautifully before even contemplating to freewheel from there.
> Additionally, I find that the key problem with bloated models stems from missing domain models (often has-many-through models). Not from moving the logic of the existing models into more noun classes.
When I first started learning Rails 4 years ago, I watched a video of a talk you gave where you refactored a kludgy piece of code to use an additional resource/model. The code unraveled before our eyes.
> That's like arguing that if your book is longer than 300 pages, it must also use really big words and complex sentence structures. What?
I don't think this analogy applies. If my house is full of things, I prefer to put them in small, well recognizable boxes, instead of in one gigantic mess. This is simplicity too.
Just food for thoughts, I forked DHH's implementation and modified it to support a bigger structure (so you can keep stuff in different files/class). I haven't tested the file so it may contains bugs, I apologize if it does.
The file name contains dash(-) replace them with slash(/) as github doesn't like path.
Love when people play code ping pong. There's too much talk and not enough play in these threads. But I have to ask you, do you really think that splitting out those two classes improved things for the example? Or was this just future coding for possibly-maybe extension points? Because from where I'm sitting, it made things less clear and harder to follow with no additional upside.
In the context of your example, your implementation is the best, hands down.
My fork had two objectives. The first was to nail the argument of "What do I do if my model has 1.2k LOC". Look at it as an extension of your solution.
The second was to show that before using Policy, there is mechanism in rails that you can use to extract bit of code away from the model (concerns, validators, etc.)
So yeah, you could say this was a future coding for possibly-if moons are aligned- extension points ;)
To reiterate, I start with in-model validation 100% of the time and move from there as needs be.
I don't think your model has to have 1200 lines of code to see the benefits. DHH's ticket class stars with 2 lines of model code, which is a very rare case in the Rails applications I've seen. Counting by hand, I see DHH's example has one, two, three...
Twenty-six (26) lines of model code that are dedicated to validating this specific "confirmation" validation.
Given that validation is just one of the concerns of models built with The Rails Way, imagine sprinkling all of the other code that a model will have in-and-around these 26 lines of code. The central purpose of those 26 lines of code vanish into the fog of the rest of the model, creating the mystical behaviors that are common in some Rails applications.
I totally understand the concern about preemptive architecture, but once the code count for a given behavior creeps from 4, to 8, to 12... it's time to organize it into some sort of central place that's isolated from the rest. I mean, gosh, we know how this works in the real world, right?
Dev A: Here's my 26 lines of validation code to the model, DHH says it's the right thing to do.
Dev B (hours later): I need to add a little bit of behavior here, but I'm only adding a little bit of code. I'm not going to try to deduce what all of that code does, so I'll just tack mine on the bottom.
Dev C (days later): I have to add a bit of code... hmm... this is sort of a mess, I see mostly validation code but I also see some behavior. I'm not touching any of it. I'll just patch my stuff here... and here!
[iterate over and over, you get a mess of a Rails app]
I've seen this happen to multiple Rails applications... Rails applications built by experienced developers who know Rails in-and-out.
Plopping a bunch of code in something as important as a Rails model and leaving the cleanup for the next dev isn't very polite.
The theme I'm seeing in this series is a desire to add a layer between controllers and the domain. This new layer seems closer to the controller than the domain (it always acts upon the domain) so are you not simpler making the controller layer thicker? By removing logic from the domain you're creating a distance between the information and your business policies. For instance you now have to remember when to apply particular policy objects. If the logic lived in the domain then the objects would take care of this automatically.
Fundamentally I have an issue with this whole approach, if you have bloated domain objects then organise them better (as DHH mentions a common problem is not having enough classes in your domain). Also, given the choice between bloated objects and logic separated from it's information I would take bloated objects any day.
But if you have a beef with how much of the domain logic is in the Model, don't blame Rails, blame MVC. I mean, come on.
Either you want to use MVC or you want to go in a different direction. Fine. But don't blame Rails for being a good MVC implementation. Instead, formulate your own, new "philosophy" about how this all should work.
While I don't generally acknowledge the validity of "Before you criticize, think of something better", in this case I think it's appropriate. You appear to be critical of the whole MVC philosophy. And that's FINE. No problem. But before you go criticizing Rails I think you should formulate your own philosophy of how it all should work instead, rather than blaming Rails for doing what it is supposed to do, and doing it well.
I guess where we diverge is the amount of domain logic which lives on an ActiveRecord model.
My experience is relatively limited, but in 4 or so years of professional Rails development, across many different codebases, the overwhelming majority of problems have been caused by bloated models with too many responsibilities.
You clearly have more experience with Rails, but your solution always seems to be "If you were smarter, you wouldn't have these problems with my framework". I've seen this problem recur again and again across multiple teams & codebases.
We're seeking to address that problem with these concepts that have been successfully used in other frameworks & languages.