A well-known anti-pattern is the blob one i.e., a workspace - or more accurately a space - where everything is mixed up together, ending up with tight coupling, blurred boundaries, high maintenance cost, low ability to evolve, and more…

• No structure. No discipline.
• No relationship pattern e.g., random dependencies.
• N-flavor projects… Like candies, we cannot be sure of what we get and it does not necessarily taste good.
• Unpredictable behavior i.e., what happen if… or could I add/remove/swap/…

To tackle this, most of the architecture patterns introduce layers. Layer is a common way to:

• Define scope by gathering stuff that shares same semantic/trait/… together.
• Define boundary and act as bulkhead partitioning, guarding one bunch to be noised/modified/broken by other ones.
• Define coupling and communication rules between those bunches

Hexagonal architecture is one of those particular layered patterns that gains some exposure in the past two decades and that deserves attention as it structures the way we think about crafting modern software.

Nobody wins Olympic Games without training for a while upstream. Such applies to patterns. They need to be exercised, so hands-on as soon as you can to fully grasp the intent and how all the parts fit together. If you cannot manage to apply them in a tiny and partitioned environment, you are doomed to fail when asking to do so in a more global scale.