This is a really lazy complaint that gets reiterated when this approach is mentioned. There's no elaboration here to provide substance to the argument.

When I think stereotypical enterprise java complaints, I think people joking about AbstractFactorySingetonProxyBeanAdapterFacadeConcrete. Not this. Whether you agree with the approach or not, it's fair to say that the author is simply drawing some boundaries around his/her business logic to make it framework agnostic, decoupled, and test-speed friendly.

Are you really this afraid of software architecture, that anything that goes beyond simple MVC is enterprise java?

The hallmark of enterprise java is the incidental complexity needed to implement a given abstract architecture due mostly to the strict limitations of the core language. Ruby's more powerful system allows you to implement architectures with an order of magnitude less ceremony (and some would argue safety) and without as much careful planning required to make sure every possible hook is in place up front. In the end, "enterprise ruby" architectures bear so little resemblance to enterprise java that the comparison is nonsensical.

There is a lot that Java EE got wrong, but there is a lot in there that is probably more good than bad. The amount of ceremony and effort (and XML) required to get a basic Java EE thing is not great. But, when I used Play Framework 1.x with Java, it was quite enjoyable. I haven't used it much since, but I could see something like Play solving most of the annoyances of Java EE, while keeping some of the good parts of Java or other JVM languages.

well, JEE works but it's not pragmatic. Rails brought pragmatism and good developper experience to all other web plateforms. And Ruby is still a very pleasant language to write.

At the end of the day your product is your app running or not,it doesnt matter own much design pattern you implemented in your code.That's pragmatism.

Exactly what I thought!