Software is a creative endeavor and a craft. And like any creative endeavor and any craft, it is subject to fashions. About a decade ago, one of those fashions was Hexagonal Rails largely inspired by the DDD book, but also by the original Hexagonal Architecture work by Dr. Cockburn.
Some of these applications are now up for their Rails upgrade and an “oil change,” and it’s interesting to see them in the wild and how they get perceived through the lens of the years that have gone by since then. I call them “hexatetrahedral Rails applications” - in jest, of course - because they often end up presenting complexities that go beyond the intended benefits, sometimes becoming what I’d describe as complications or even complicationments.
And while I appreciate the good intentions behind this approach, I’ve found myself questioning whether the benefits outweigh the costs in most cases. So I felt that - at the very least - I want to suss out why it is valuable, but also - figure out how I define/detect those apps in the wild, and how to understand their raison d’être well. Not to be snarky - but to look for the nuggets of wisdom in there which can be useful for us, today.
Why the vitriol?
I use this term from time to time because I’ve observed teams struggling with the maintenance and evolution of applications architected this way. While most “adult” Rails codebases (anywhere from 7 to 18 years of age) tend to be messy, that mess usually is within the confines of the knowable and well-discovered Rails builtins - ActiveRecord, ERB, controllers, helpers, the works.
Hexatetrahedral apps, in contrast, present a different paradigm which is usually (not always) supplemented by a large amount of non-default tooling. That tooling also needs updating. It needs to be understood. It is often coming from a single person who might have either abandoned it, or decided to redo it nearly from scratch. The burden of maintaining those “divergent” dependencies is much higher than “just updating the Rails app.”
And all of that also comes with a lot of dogma, usually:
No, you shall not do a User.where directly, you have to do a UsersRepository.find_all_with_email(...) .
That setup often adds indirections that don’t necessarily improve the expressiveness of the codebase, while making changes more complex - because, for every change, the engineer needs to decide whether they will be dropping this “repository” or “domain design” approach and just hit the ActiveRecord subclasses directly - or keep up the approach of going through “the published pathways.”
The Original Premise
... continue reading