Ports & Adapters

One important thing we need to remember on the subject of hexagonal Architecture is that it could have been Hendecagon Architecture or Octadecagon Architecture. The number of sides is actually not important as these symbolize the ports and adapters that form the connections points to the system.

The basis of the architecture can be explained as having the Domain of your system as a core surrounded by an Application shell, which in turn is surrounded by a Infrastructure shell. The Domain should know nothing about the layers around it. The Application layer knows about itself and the model layer and the Infrastructure layer knows about all three. This means that the high level concepts as our Domain entities know nothing about how they get stored or what calculations they depend on. If they need to call such methods they have an interface that can have multiple implementations depending on the application or infrastructure needs without them having to know anything about the chosen implementation. On the other hand the piece of code that saves these entities to the database needs to know about the entities but it can be replaced without the need for the domain code to change.

Stop me, if you heard this before

The basic concepts of the Hexagonal Architecture are maintainability and dependency Inversion. And while Marco mentioned these concepts, I still had this feeling throughout that I had heard all of this long before. The reason for which came to me while discussing the presentation with a few colleagues afterwards. These concepts and this way of working had been taught to me in my college and university classes. The basic idea of always depending on interfaces and to have high level code not depend on implementation details of low level code, is a common best practice that is not unique to hexagonal architecture.

Conclusion

In the end I feel that the presentation was maybe a bit flimsy but that is probably, because the concept of Hexagonal Architecture is rather simple and straightforward. Thankfully the presentation was followed by a live code demo. This demo clearly showed how simple it is to replace certain parts of the code without touching the other layers. It also showed how this makes testing easier as stubs/mocks can simply replace interfaces. Unfortunately it also showed that this architecture runs the risk of having a high class density for even the simplest functions, though this might be an artefact of it being a demo. All in all, I would not say this presentation was an eyeopener nor that Hexagonal Architecture is the next silver bullet but I did go away with a reminder of important basic concepts and my brain trying to apply these old lessons to my current projects.