Advantages of the hexagonal approach

If you're looking for a pattern to help you standardize the way software is developed at your company or even in personal projects, the hexagonal architecture can be used as the basis to create such standardization by influencing how classes, packages, and the code structure as a whole are organized.

In my experience of working on large projects with multiple vendors and bringing lots of new developers to contribute to the same code base, the hexagonal architecture helps organizations establish the foundational principles on which the software is structured. Whenever a developer switched projects, he had a shallow learning curve to understand how the software was structured because he was already acquainted with hexagonal principles he'd learned about in previous projects. This factor, in particular, is directly related to the long-term benefits of software with a minor degree of technical debt.

Applications with a high degree of maintainability that are easy to change and test are always welcomed. Now, let's learn how the hexagonal architecture can help us obtain such advantages.

Change-tolerant

Technology changes are happening at a swift pace. New programming languages and a myriad of sophisticated tools are emerging every day. To beat the competition, very often, it's not enough to just stick with well-established and time-tested technologies. The use of cutting-edge technology becomes no longer a choice but a necessity, and if the software is not prepared to accommodate such changes, the company risks losing money and time in big refactoring because the software architecture is not change-tolerant.

So, the ports and adapters nature of the hexagonal architecture gives us a strong advantage by providing the architectural principles to create applications that are ready to incorporate technological changes with less friction.

Maintainability

If it's necessary to change some business rule, you know that the only thing that should be changed is the Domain hexagon. On the other hand, if we need to allow an existing feature to be triggered by a client that uses a particular technology or protocol that is not supported by the application yet, we just need to create a new adapter, which we can only do in the Framework hexagon.

This separation of concerns seems simple, but when enforced as an architectural principle, it grants a degree of predictability that's enough to decrease the mental overload of grasping the basic software structures before deep diving into its complexities. Time has always been a scarce resource, and if there's a chance to save it through an architecture approach that removes some mental barriers, I think we should at least try it.

Testability

One of the hexagonal architecture's ultimate goals is to allow developers to test the application when its external dependencies are not present, such as its UI and databases. This does not mean, however, that this architecture ignores integration tests. Far from that – instead, it allows a more continuous integration approach by giving us the required flexibility to test the most critical part of the code, even in the absence of technology dependencies.

By assessing each of the elements comprising the hexagonal architecture and being aware of the advantages such an architecture can bring to our projects, we're now furnished with the fundamentals to develop hexagonal applications.

Next episode we'll learn how to wrap business rules inside domain hexagon.