Into the hexagon
or going from a cake to an octopus
Long time ago I’ve read an article on programming which mentioned something about the importance of “knowing where you poop” when developing software (I suspect the article was on codinghorror.com, but I failed to find it there later, so I might be wrong). The author made an analogy that even though you can physically take a dump anywhere in your house, you would off course never actually do that, and are instead taking your “unloading business” in a specific section of your home dedicated for that - the toilet.
In the previous article I concluded that my fellow developers were struggling to figure out “what goes where” in the layered architecture and they leaked tech-specifics into the application domain.
If we:
know that the layered architecture is one of the most common ways programmers use to structure their code,
assume that majority of programmers out there in the wild are exhibiting similar symptoms and
apply above mentioned metaphor
, it is safe to assume that a lot of developers might be running around like children not knowing where the toilet is and are swimming in their own poop 💩.
This is definitely not right.
All this ambiguity and confusion on how to structure code and where to put things comes from this idea that our mental model of software should be a series of layers stacked on top of each other. Let’s forget about that idea for a moment.
Instead of imagining multiple top-down layers, lets imagine a single, central core of the application which is surrounded with plugs (ports) which are the only doors for the application to the outside world. You can have any number of these plugs that communicate with the world. This is a very important distinction from the traditional layered architecture, where you aim to model everything with a limited set of layers. With the hexagon there are no limits - there is one core and any number of I/O ports.
So the idea is to go from this:
, to something like this:
At first, the drawing might seem scary or more complex than the regular cake you are used to working with. However the actual concept is not. In fact, the core idea is quite trivial.
There is the “center” and there is an “outside”.
That's all.
That's your app.
“Center” contains your domain model. This is the brain of your application and, as accurate as possible, code representation of your mental model of the problem that you are solving.
You do not poop here. No mappings, database nuances, juggling with HTTP, transactions, entity flushing, etc. None of those things should ever go here. Your grandmother should be able to read this code and to be able to guess what you are building.
“Out” is the bridge linking your domain model and the outside world. This is where all the “techy” stuff goes. Don’t bother boring your grandma with this unless she is a programmer.
Those are all the rules.
And they cover everything. Essentially every application can be viewed as a simple machine able to receive inputs and produce outputs. Thus the only thing essentially necessary to structure any such application is the core and the I/O.
By using this simple structure:
you should never be in doubt about “what goes where” and
making sure your domain is not polluted with non-domain code will be more straightforward.
Alistair Cockburn is the one who coined the term hexagonal architecture and proposed it in 2005.
He is also one of the signees of the famous agile manifesto. He is not in the agile manifesto photo, but the rumor is that he is the guy that actually took it.
Jeffrey Palermo proposed something similar with the concept of the onion architecture. What he did is very similar to hexagonal architecture, only he went further with decomposing the core part in several concentric rings (hence the 🧅).
Also, in his talks Robert C. Martin often emphasizes the importance of recognizing the I/O parts of your application and the importance of differentiating your core application from its inputs and outputs from/to the outside world. In 2012 Uncle Bob defined the concept of “clean architecture”, and this concept shares a lot of similarities with Alister’s hexagon (or at least the things that distinct these two from the traditional layered architectures share a lot of similarities). The core ideas that both share are:
knowing what are the ins and outs that your application uses to interact with the world and
separating those from the core of your application.
Essentially - knowing where to poop.
There are two reasons why I focused the whole series of posts only to the first one and not to the other two.
First one is simple - so far I used only the first one and not the other two. It is kind of like an affinity you develop towards your first car.
Second one is related to the difference in the value-add between them. Alistair was the first one who proposed to ditch the layers, to view your app as a core surrounded by I/O and to segregate tech from your domain. Jeffrey and Uncle Bob added further decompositions of the domain model on top of that. The reason I like hexagon’s simplicity is exactly the fact that there is nothing telling you how to structure your domain. Structuring of the domain is left to the implementer. You can have no concentric circles inside of your domain or you can have nine of those if you’d like and call it “Dante’s architecture” if you are really into that - nobody cares. What does matter is the shift in perspective from layers to the in & out. This is where the bulk of the value lies in my view.
The aim of this series of posts is to share my interpretation and experience with the hexagonal architecture. Note that this interpretation might completely differ from what Alister proposed and it might turn out that parts of it will even be simply wrong (although I hope there will not be many such instances). The idea is to communicate, share experience and learn more.
Join me in the next article where we will try to get our hands dirty and build our first hexagon.
Alistair Cockburn’s original article
Robert C Martin’s talk on “clean” architecture
EDIT: The 💩 article