Though Hexagonal architecture has many benefits, these benefits are only superior within a limited set of corporate styles and methodologies. One of these is that Hexagonal architecture requires that all business logic features, whether fully defined in advance or defined at a later "on-demand" moment, are always fully defined and documented before implementation.

This requires an extra effort to document and keep all the functional decisions that lead to the implementation to be stored in a way that can be easily referenced, both for the implementation stage and for reference when revisited in the future.

But when a project does not have a clearly defined business logic feature to be built, this SOLID way of working becomes an obstacle. When your input adapters or output adapters are not specified or cannot be specified beforehand, then you find yourself constantly going back to redefine your ports during the development process.

In a similar scenario, if you are working on a project with a resource starved team, you may lack the time and budget to take the extra time to write out the definitions. The temptation to cut corners due to outside pressure may become so great that the implementation starts skipping layers and isolation, eventually resulting in a worse version of spaghetti code than with a more traditional layered methodology.

In addition, in both previous scenarios, the temptation to skip writing or updating the changes in the functional documentation is great, which has a huge impact on another shortcoming of Hexagonal architecture.

The shortcomings of Hexagonal architecture are not limited to just organizational challenges, but there are significant problems in working with the resulting code as well, though they may not exist in a properly resourced, fully experienced Hexagonal architecture team. But when one of these big shortcomings does rear its head, it turns Hexagonal architecture into a burden again.

Let’s take bug tracing as an example, especially bugs that are not hard failures in the code but rather missing features or eroneous data. In a more traditional architecture, the route that the code follows is usually easily traceable by just reading up on the code. Jumping from call to call to read along and figure out what goes wrong and what is missing at the point of failure is a vital requirement to quickly solve broken functionality. With Hexagonal architecture’s layer uncoupling it requires an exponential factor of extra, often disjointed, traces to get to the point where the exception occurs, at which point backtracking becomes even more difficult when required to find a missed step in preparing data that is the ultimate cause of the bug.

And there is yet another real world challenge to consider. If you have a fixed, long term dedicated team with members that will reliably stay employed for a long period of time, everyone will know all the requirements that the application is or should be built to. But what if you don’t?

In a project where the team is outsourced, relies on temporary employees, or doesn’t have a team at all, the extra cost of entry to the team will require a lot of reading up on the design decisions to allow for both maintenance and development of new features. Especially the project without a dedicated team scenario is highly susceptible to improper continuation or even rogue changes as there is no mainstay person to keep the code up to standards.

The focus of this article was to look at the flipside of Hexagonal architecture and is not written as a guide to choosing the right architecture for you. All architectures have their good and bad sides and suggesting that there is any kind of non-content, objective advice I could give would be making exactly the same mistake that brought you to this article in the first place.

So, what should you use? It depends. That being said, there are many alternative methodologies out there to choose from and in general, falling back on a simpler but well maintained multi tiered architecture may give you a better code base than forcing yourself into Hexagonal architecture.