Ok, let me throw out a different perspective, why are you even using an ActiveRecord Model as your entities in the first place. That in itself violates the Single Responsibility Principle by attaching the persistance mechanism to the entity itself.<p>What if your entities were just objects that held data and did validation, but you let use case objects determine the behavior of your system beyond that? Data persistance at that point is literally persisting your entities to the DB.<p>Then you use the DB much more like you would a filesystem - to retrieve and save data. It doesn't determine your model, it just stores and retrieves your data.<p>So, you end up with 3 types of things in this system... entities, use cases, and data gateways.<p>Your data gateways can still use AR if you want, or something else, it doesn't matter.<p>This isn't my idea, Uncle Bob lays it out better than I can here: <a href="http://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-architecture.html" rel="nofollow">http://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-arch...</a>
Ok, time to embarrass myself due to lack of Ruby/programming knowledge. A few questions that perhaps someone can clear up as from my OO perspective this, to me, is all over the place. I must admit I'm only just getting started on Ruby.<p>Firstly, that doesn't look like the strategy pattern to me, isn't it back to front? And even if it were, what the hell are you doing? You do not pass the user to the authenticator, you'd pass the authenticator to the user constructor.<p>The way you've chosen is very brittle, it's a sure fire way to accidentally shoot yourself in the foot later on when someone accidentally deletes the authenticator or adds a new code path that doesn't contain one.<p>I also don't understand why you're creating a new class per object query? Ditto for the policy stuff. Why not just use a repository object if you don't want to clutter your main class. Like OrderRepository.GetByCompany(Id).<p>As for point 7, I don't understand why you're not completely extracting the facebook integration from the comment class. Does Ruby not have events? Why aren't you firing an event that the facebook integrator that initialized on the user object subscribed to? i.e. make a facebook integrator that registers itself on the user object creation.<p>Also, "View Model" not "View Object", that's what they're called, a lot of other frameworks already use them.
This is more of a theoretical question, but at what point does a project become large enough that concerns like this begin to truly matter?<p>When doing a small, limited-use project, it seems often that trying to follow "best practices" like avoiding fat models would be more trouble than it's worth. And yet I've worked on larger enterprise-scale projects that have most certainly benefited from following this and other practices.<p>Anyone know of any research or work on where the tipping point is for following increasingly complicated patterns and practices?
I don't know anything about Ruby, but it's interesting to see typical "enterprisey" patterns appear for people using these scripting frameworks for web-app development. One thing I've always been curious about when evaluating Python frameworks, or looking at Ruby on Rails sample code in Github was how apps look when they start getting large. I usually see a mess, and it sort of turned me off. It's nice to know that some of the same patterns are being though of and applied in these worlds, too.<p>Also some good comments below on not just jumping into using all these patterns on smaller projects. Take the benefit of being light and nimble starting, then start breaking things apart as the app and teams grow. Best of both worlds.
I like Ruby on Rails, but "coming" from a Java background I find it odd to have lots of stuff in the models instead of using utility classes or services.
Cool stuff. @brynary, how do you organize your app? Are all seven techniques dumped into app/models or do you keep each technique in its own directory?
Perhaps it's my lack of training or the projects I work on, but I've never seen a Rails model so large/cumbersome as to justify even one of these techniques.<p>Is this a case of fixing the wrong problem?