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.
Oh, no I have no problem with enterprise Java - it was merely an observation. Enterprise Java exists because it works, after all. I just find it interesting that most software projects will eventually come to the same conclusions regardless of their original source.
Actual hexagonal design is useful software architecture. It may just be extremely poor presentation, but I am far from convinced that the dictates in the article, or the very little bit of very abstract sample code it provides, reflect useful architecture (Hexagonal or otherwise) -- certainly, its not a presentation that fosters understanding and intelligent application over cargo-culting.
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.
absolutely absolutely this. Patterns don't suck. Implementing patterns in Java sucks. Ruby's got a lot of fantastic things going for it, and duck typing means you don't have all the ceremony of defining and implementing interfaces.
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.
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.