{"id":2787,"date":"2025-08-28T07:31:23","date_gmt":"2025-08-28T07:31:23","guid":{"rendered":"https:\/\/inprotech.es\/?p=2787"},"modified":"2025-08-28T07:31:23","modified_gmt":"2025-08-28T07:31:23","slug":"ports-adapters-hexagonal-architecture","status":"publish","type":"post","link":"https:\/\/inprotech.es\/en\/ports-adapters-hexagonal-architecture\/","title":{"rendered":"Ports & Adapters (Hexagonal Architecture)"},"content":{"rendered":"

In its evolution throughout its history, software development and the different schools of architecture with traction in the community have been solidifying a series of essential pillars when planning applications: maintainability, scalability and flexibility. Without them in mind, the universal tendency for systems to increase in complexity as they grow establishes a more or less defined ceiling beyond which a program could not grow, at the risk of becoming completely ungraspable by a person trying to enter the project, or tremendously fragile to change and therefore impossible to update and scale.\u00a0<\/span><\/p>\n

\"\"
Figure 1: Alistar Cockburn<\/figcaption><\/figure>\n

One of these architectures that have earned a place as widely known and used patterns beyond the theoretical circuits is that of Ports and Adapters, proposed in 2005 by Alistair Cockburn<\/span>1<\/span>, also known for being one of the driving forces behind the Agile<\/span>2<\/span> methodology. The basic idea of this architecture is the decoupling of the application’s core from its input and output mechanisms, allowing for greater modularity and testability.\u00a0<\/span><\/p>\n

InprOTech Guardian<\/b>, our advanced cybersecurity solution for OT networks, is proprietary software written with these architectural principles at its core. In this article we will explore the fundamentals of this architecture, its structure, advantages, disadvantages and how it is implemented in practice.<\/span><\/p>\n

 <\/p>\n

Origin and Motivation<\/b><\/h2>\n

Alistair Cockburn introduced the Ports and Adapters architecture as an answer to certain typical problems derived from object-oriented development: excessive and\/or superfluous dependencies between layers, impossibility of replacing elements adjacent to the application by test or test systems, and filtering of business logic outside its application range. Its main objective was to solve the problems of excessive dependency on external interfaces, which hinders the evolution and maintenance of systems.<\/span><\/p>\n

Problems in traditional architectures<\/b><\/h2>\n

Traditional architectures often present problems such as:\u00a0<\/span><\/p>\n