Before you decide to use the Hexagonal Architecture, consider these scenarios where it may not be the best choice.
Hexagonal architecture (also known as "Ports and adapters") was defined by Alistair Cockburn in 2005. The main idea behind this pattern is a separation of the core of an application from its external dependencies.
Naturally, hexagonal architecture provides a clear separation between the business logic and the ways the system communicates with external systems, making it significantly easier to test and maintain the code.
While hexagonal architecture can bring many benefits, there are certain scenarios when it may not be the best choice.
1. Team has no experience with this pattern
Hexagonal architecture is a relatively new pattern, and they're not so many developers who can use it well. If the development team does not have enough experience with the Hexagonal architecture pattern, it may be better to choose a simpler architecture that is easier to understand and implement, for example, 3-layer pattern described here.
2 Small systems or short-term projects.
Hexagonal architecture is a relatively complex pattern, and it involves multiple layers and components. As with many other architecture patterns, there's some initial implementation cost. In bigger projects, it usually pays off with time. On the other hand, in smaller projects, it might never pay off.
3 Legacy systems
Integrating hexagonal architecture into an existing legacy system can be very challenging task. Hexagonal architecture uses rather unusual terminology which will look alien and cryptic in some older systems. As many older systems were implemented in some form of N-tier architecture, using 3-layer pattern can be a better choice.
3-layer pattern is hybrid pattern inspired by both N-tier and Hexagonal patterns.
4 Performance-critical applications
Hexagonal architecture introduces additional layers of abstraction between the core logic and the external dependencies, which can impact the performance of the application. While usually negligible, for applications with particularly high performance requirements, such as real-time or trading systems, I would suggest considering other patterns.
It is important to carefully consider the requirements and constraints of the project, as well as the skills and experience of the development team, before deciding what architecture pattern you should use.
Top comments (0)