Someone has to say it: Damn, this looks fucking ridiculous! First we have the false modularity. You see a bunch of separate stuff (classes, methods, whatever)

Someone has to say it: Damn, this looks fucking ridiculous! First we have the false modularity. You see a bunch of separate stuff (classes, methods, whatever) and think "Wow, nice, now we can reuse this all over the place!" The truth is that these policies/services/renderers are going to be complected; you're going to create them in triplets as you implement your application. Moving things around doesn't make them modular. They can only be modular if the author actually implements them in a modular way (and you can do that in Rails today). The DI-framework can't handle change at all: class CurrentUserResolver def initialize(user_finder = User) @user_finder = user_finder end # note that resolvers themselves get injected def call(session) @user_finder.find_by_id(session[:current_user_id]) end end What if I later need the cookies/params to detect user session? If I changes the #call method, every single test breaks. And then there's the added complexity. Now I need to keep track of the route-mapping, default policy, route policies, the route service and the route renderer. Which are now in several different files. And there's not even a clean class-to-file mapping to help me locate it. Oh, and the premise of testability. Well, this makes it very easy to test units itself, but the more you split your projects into smaller units, the more bugs occur when you mix the units. Sure, you can get your precious fast test runs (and a nice green test), but in reality you're only testing a single unit of a complected app. EDIT: This reminds my of Rick Hickey's quote from keynote at RailsConf2012: ""We can make the same exact software we are making today with dramatically simpler stuff—dramatically simpler languages, tools, techniques, approaches. Like really radically simpler—radically simpler than Ruby which seems simple.""