I'm not a huge fan of Rails architecture neccesarily, but I have to admit I have trouble following the 'hexagonal architecture' stuff, even in simple examples like this.
It does seem to be a lot of abstraction. Of course, with abstraction comes flexiblity, that's the point, I get it. But with (some kinds? all?) abstraction also comes complexity and cognitive load for the developer. If you're not careful, you end up in Java FactoryGeneratorFactory land.
(I hope the next step in the 'hexagonal architecture' isn't using an XML file to specify all the linkages and concrete classes in use. How else do you specify what concrete @db etc your controller is instantiated with?)
... and of course for those who applies modern Java development patterns, we no longer see plenty FactoryGeneratorFactory.
I find it a bit odd that the community who has railed Java hard suddenly came up with something more complex than... gasp... the solution in Java-land.
I didn't mean to imply that everything in Java was over-engineered, just that certain historical common Java practices were examples of what happens when you over-abstract and over-engineer. Certainly over-abstracting and over-engineering happens in every language too though, it's a hazard of the trade.
What community is it that you think has "suddenly" come up with what solution that's more complex than what "the" solution in Javaland? I'm not even sure what you're talking about. There are of course many solutions in Javaland, naturally, and in every other code land.
I think engineering code, especially code shared between multiple developers/installations, is a constant tension between simplicity and abstraction/flexibility. It's sometimes possible to optimize both, but it requires a lot of skill and a lot of domain experience, and domain experience especially seems to be under-valued and under-present in the current environment. (Plus if the domain changes fast enough, nobody ever has enough domain experience!)
I think individual developers, as well as teams and communities (language-based or industry/domain-based) often swing from end to the other. This legacy thing is too complicated, let's start over with new principles to keep it simple! This simple thing isn't as flexible as I want, let's add in some abstraction to make it possible to do what everyone needs; then do it again; then do it again; then start over at 0.
It does seem to be a lot of abstraction. Of course, with abstraction comes flexiblity, that's the point, I get it. But with (some kinds? all?) abstraction also comes complexity and cognitive load for the developer. If you're not careful, you end up in Java FactoryGeneratorFactory land.
(I hope the next step in the 'hexagonal architecture' isn't using an XML file to specify all the linkages and concrete classes in use. How else do you specify what concrete @db etc your controller is instantiated with?)