Hexagonal architectures

One of the most common software development’s problems in the last years is linked to the insight of business’ logicals in the user interfaces’s code.

26 giu 2015

One of the most common software development’s problems in the last years is linked to the insight of business’ logicals in the user interfaces’s code. The problems that derive from that can have different interpretations: the system can’t be supported by automated test suite because some of the logical that have to be tested depend on UI logical, that is characterized by a higher variability than the business one; because of that, it becomes impossible to replace human contact in the system with batch operations and it becomes difficult when it’s not impossible to let another system steer the one in exam. This requirement is much more felt than a decade ago, because the applications have to interact with system that before weren’t considered as extern systems (such as smartphones or tablets) that comunicate in different formats or automatic systems like supervision or events management ones.


The suggested solution is to define a new layer in the architecture, with the promise that none of the business’ logical will be implemented, but because this border is teorica and there isn’t any mechanism that can guarantee this rule’s respect, with time the promise is going to fail and the old problem reappears.


Imagining that every feature exposed by the application can be usable through an API, a test regression’s suite could be organized. Domain’s experts could define mechanized test case before that the UI details are finalised. The API’s disponibility would support the application’s distributions, so thatother programs could consume their features without requiring human intervention and similar observations can be done about data system’s persistenxe: the possible database’s unavailability shouldn’t compromise the development phase.


And so we understand how a “layered” approach would be too weak against those reflections and in that sense the hexagonal architectures (also named as ports and adapters) introduced by Alistar Cockburn, according to whom the application during the development must be isolated from the external systems, with which he communicates thanks to ports that define a communication protocol (API) and adapter, that authorise to the different worlds to comunicate. In a classic layer architecture, the reading is from the top to the bottom (also from left to right in the case of n-tier architectures); in that case the reading is from the center outward. In a n-tier architecture’s contest, there’s an asymmetry between users and contacted systems: the first ones act as principal actors, those who guide the application, while the contacted systems are the secondary actors. It takes form the application as an isolated core from everything that orbits around. The architecture can be compared to the one of a operating system when every device (external system) that adheres to a port’s protocol can be linked using kernel mosules’ (adapter).


A GUI is an example o fan adapter that maps the user’s actions on the port’s API. The application communicates with external entities to recover datas on with it operates: we are in presence of a database-type protocol, but from the application’s point of view if the SQL databese get substituted from a file or from a NOSQP database, the API shouldn’t change, but a different adapter should be substituted to operate on the same port. For a lot of different applications two ports are enough: the UI and the database. This simplification can involve to the creation of applications with a mono-dimensional rappresentation, with three, four or five layers. But we find at least two problems related to that choice: the first (and the worst) one implies that people tend not to draw a net line between the layers, getting into the problem told at the beginning, that the application’s logical doesn’t stay confined; secondly, there could exist more than two ports for the application, and so the mono-dimensional rappresentation becomes inadeguate. The hexagonal rappresentation offers to point out the asymmetry between what’s outside and what’s inside and the presence of a defined number of different ports. Those don’t have to be necessarily six, the hexagon is symbolically elected because it allows an easy rappresentation of the ports and adapter’s number which people need. So the term “hexagonal architectures”  was born from the visual effect. The terms “port” and “adapter” catch the rappresentation’s target: for every port can be defined more adapters for the different technologies that can fit that port.