This session has concluded watch the replay or download the slides below.
Table of Contents
Common pitfalls when scaling applications
When scaling applications, two common pitfalls often arise: spaghetti code and a lack of proper testing. This can occur for various reasons, but one of the most common reasons is the lack of a coding style guide or an overarching design structure.
For instance, when starting a project, it’s fairly simple. An input and one or two outputs. However, as the project grows or the requirements expand, programmers can resort to an experimental approach each time a new component is added. They can also resort to using manual testing—which works for simple unit tests for small projects but overtime becomes too cumbersome.
The lack of a design structure makes projects prone to gradually growing complexity. As a result, the experimental app ends up in production as an inefficient system that demands continuous maintenance. To avoid breaking essential business logic and harming the overall business, developers allocate unnecessary development time to making one-off solutions. The time and effort is compounded due the previous iteration’s shortcomings.
Using hex architecture can help address scaling issues.
Hex structure vs traditional three-layer architecture
There is nothing wrong with the traditional 3-layered structure composed of the presentation tier, the application tier, and the data tier. And for most applications this will usually be enough. However, theoretically, as you add more business logic and more functions, the complexity ramps up exponentially. In that case, a traditional approach may no longer be the most efficient. You can always scale and automate by expending more resources, or you can take a step back and reorganize your resources.
A hex structure, contrary to what the name suggests, is not a 6-tiered structure. Instead, it’s an analogy for the freedom of a developer to add ports and adapters—sort of like a honeycomb structure where you can keep adding more hexagons and there would still be no gaps. In the traditional approach, the presentation, business, and data side flow directly to each other; in hexagonal architecture, you add interfaces (or buffers) in between fully functioning components making them semi-autonomous. You would only have to think about how what data passes from one to another and how communication is processed.
Fortifying your app with hexagonal architecture
The Hexagonal architecture provides a solution to this problem by utilizing dependency inversion control, which separates business logic from implementation details like databases and REST clients. It also fosters a clear separation of concerns between components, ensuring a more organized and manageable application as it grows.
Ports and Adapters
As the name suggests, hexagonal architecture utilizes standalone components with a functional core in the middle of the design structure. This means that expansion, maintenance, and designing is easier because the program’s components and roles are clearly defined. Buffers between these components allow easy addition and removal as well as facilitate efficient communication among the program’s functions.
So how do you initiate a program with a hexagonal design structure? Watch our short presentation hosted by Nuno Castro to get a brief introduction and some great examples. This session has concluded. Browse the presentation slides and replay below.
