Get the latest tech news

Hexatetrahedral Rails

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.

The original premise is actually quite sound, and shares similarities with other well-regarded layering propositions such as “functional core, imperative shell” and is based on composition of modules over small interfaces. Why I need to use Repositories is not explained in this statement, neither is the question answered as to why tight coupling to Rails primitives is that bad, nor why I should pick this particular flavor of architecture to help my… legacy code challenges. I think this was actually the main desire of the hexagonal architecture (but also of Packwerk, and other similar efforts) - and while we have made progress since the early 2010s on structuring our Rails apps better, we haven’t yet cracked this puzzle.

Get the Android app