About the cake
or "one of the most common architectural styles"
Before going deeper into explaining hexagonal architecture and why every programmer should know about it, I will take a bit of a step back to talk about a cake.
Most of the applications I worked with in my career were structured in multiple layers - so somewhat as a cake.
No wonder this is so, when you try to google “layered architecture” this is what you’ll get:
Even Google bolds the fact that the layered architecture is the leading pattern for structuring your applications. There are a lot of articles out there that state it as the de facto standard in any application development.
I believe this should change.
Don’t get me wrong, I don’t think “cake architecture” is some anti-pattern-monster or something. Nor do I believe that hexagonal architecture is something radically different. It is not. It is a view on the same thing from a different perspective. I believe layered architecture served us well so far. Also it is, to a degree, a good way to think about your code. However, there is a better way to do so.
When I was doing a talk on hexagonal architecture, I asked my audience to think about an application structured with a very common 3-layer architecture (4 if you count frontend). Application was supposed to make a HTTP call to another microservice. I asked this simple question:
Answers were quite interesting:
I will not go into the details of the correct answer to the question, since this is not something that interests me. I will also ignore the fact that most people chose FRONTEND most probably because I used the word CLIENT in the question, thus unfortunately creating immediate mental association between the two in dev brains. The thing that interests me is that a room full of programmers (most of them worked with some form of inter-service communication - aka microservices) was not able to strongly agree on where to put the HTTP client in the layered architecture.
This was enlightening.
Perhaps it is good to repeat one more time the sentence emphasised by Google search - “The layered architectural style is one of the most common architectural styles.“.
Room full of experienced programmers, all of them having worked with this most common architectural style throughout their careers, could not agree where to put HTTP client in it. Not just that, but all available options were chosen.
To get a bit more insight I asked my fellow engineers to think about a use case when this application needs to listen to a queue on some imaginary message broker. I asked where would that queue listener go:
I was once again confused with results:
There were two things which surprised me with this one:
one more time all options were chosen (there was not a single option that everyone agreed to exclude) and
most of the programmers chose to put technology-specific queue listener directly into the domain layer.
At the time I did this presentation I had already worked with hexagonal architecture and was completely blown away by tremendous increase in clarity on “what goes where“ that it brings. Also, I found its ability to keep code clean and maintainable and prevent “big ball of mud”, “code rot” and leaking of tech-specifics into the domain so much more powerful than most of the other patterns for structuring code I used until then.
When I asked those two questions above what developers actually did is:
they did not agree on “what goes where” in layered architecture and
they leaked technology details (HTTP, queue listener) into the domain.
This is exactly what hexagon can help you prevent. If you want to find out how - see the next post in this series.