Hexagonal architecture (software): Difference between revisions

Revision as of 23:17, 12 August 2019

Latest revision as of 17:53, 30 July 2025

(40 intermediate revisions by 30 users not shown)

Line 1:

{{Short description|Software design pattern}}

The '''hexagonal architecture''', or '''ports and adapters architecture''', is an architectural pattern used in [[software design]]. It aims at creating [[Loose coupling|loosely coupled]] application components that can be easily connected to their software environment by means of ports and [[Adapter pattern|adapters]]. This makes components exchangeable at any level and facilitates test automation.<ref name=":0">{{Cite web|url=httphttps://alistair.cockburn.us/Hexagonal+hexagonal-architecture/|title=Hexagonal architecture|last=AlistairCockburn|first=CockburnAlistair|date=2005-04-01|website=alistair.cockburn.us|archive-url=https://web.archive.org/web/20180822100852/alistair.cockburn.us/Hexagonal+architecture|archiveaccess-date=20182020-0811-22|dead-url=yes|access-date=18}}</ref>

== Origin ==

The hexagonal architecture was invented by [[Alistair Cockburn]] in an attempt to avoid known structural pitfalls in [[Object-oriented analysis and design|object -oriented software design]], such as undesired dependencies between [[Layer (object-oriented design)|layers]] and contamination of [[user interface]] code with [[business logic]],. and publishedIt inwas 2005.discussed at first on the [[Portland Pattern Repository]] wiki;<ref>{{Cite web|url=https://wwwwiki.infoqc2.com/news?HexagonalArchitecture|title=Hexagonal Architecture in the C2 Wiki}}</2014ref><ref>{{Cite web|url=https:/10/exploring-hexagonal-architecturewiki.c2.com/?PortsAndAdaptersArchitecture|title=ExploringPorts theAnd HexagonalAdapters Architecture|last in the C2 Wiki}}</ref> in 2005 Cockburn renamed it "Ports and adapters".<ref name=Stenberg":0"></ref> In April 2024, Cockburn published a comprehensive book on the subject, coauthored with Juan Manuel Garrido de Paz.<ref>{{Cite web|firsturl=Jan|date=2014https://store7710079.company.site/Hexagonal-10Architecture-31|website=InfoQ|archiveExplained-url=p655931616|archive-datetitle=|dead-url=|access-date=2019-08-12Hexagonal Architecture Explained}}</ref>

The term "hexagonal" comes from the graphical conventions that shows the application component like a [[hexagon]]al cell. The purpose was not to suggest that there would be six borders/ports, but to leave enough space to represent the different interfaces needed between the component and the external world.<ref name=":0" ></ref>

== Principle ==

Line 10 ⟶ 11:

The hexagonal architecture divides a system into several loosely-coupled interchangeable components, such as the application core, the database, the user interface, test scripts and interfaces with other systems. This approach is an alternative to the traditional layered architecture.

Each component is connected to the others through a number of exposed "ports". Communication through these ports follow a given protocol depending on their purpose. Ports and protocols define an abstract [[Application programming interface|API]] that can be implemented by any suitable technical means (e.g. [[method invocation]] in an [[Object-oriented programming|object -oriented language]], [[remote procedure call]]s, or [[Webweb service|web-services]]s).

The granularity of the ports and their number is not constraintedconstrained:

* a single port could in some case be sufficient (e.g. in the case of a simple service consumer) ;

* typically, there are ports for event sources (user interface, automatic feeding), notifications (outgoing notifications), [[database]] (in order to interface the component with any suitable DBMS), and administration (for controlling the component);

* in an extreme case, there could be a different port for every [[use case]], if needed.

[[Adapter pattern|Adapters]] are the glue between components and with the outside world. They tailor the exchanges between the external world and the portports sthatthat represent the requirements of the inside of the application component. There can be several adapters for one port, for example if, data can be provided by a user through a GUI or a command -line interface, by an automated data source, or by test scripts.

== Criticism ==

== Usage, criticism and evolution ==

According to [[Martin Fowler (software engineer)|Martin Fowler]], the hexagonal architecture has the benefit of using similarities between presentation layer and data source layer to create symmetric components made of a core surrounded by interfaces, but with the drawback of hiding the inherent asymmetry between a service provider and a service consumer that would better be represented as layers.<ref>{{Cite book|url=https://www.worldcat.org/oclc/50292267|title=Patterns of enterprise application architecture|last=Fowler, Martin,|first=|date=2003|publisher=Addison-Wesley|year=|isbn=0-321-12742-0|___location=Boston|pages=21|oclc=50292267}}</ref>

The term "hexagonal" implies that there are 6 parts to the concept, whereas there are only 4 key areas. The term’s usage comes from the graphical conventions that shows the application component like a [[hexagon]]al cell. The purpose was not to suggest that there would be six borders/ports, but to leave enough space to represent the different interfaces needed between the component and the external world.<ref name=":0" />

According to some authors, the hexagonal architecture is at the origin of the [[Microservices|microservice]]<nowiki/>s architecture.<ref>{{Cite book|url=https://www.worldcat.org/oclc/999610958|title=Spring 5.0 microservices : build scalable microservices with Reactive Streams, Spring Boot, Docker, and Mesos|last=Rajesh R V,|first=|publisher=|year=|isbn=978-1-78712-051-8|edition=Second edition|___location=Birmingham, UK|pages=13-14|oclc=999610958}}</ref>

According to [[Martin Fowler (software engineer)|Martin Fowler]], the hexagonal architecture has the benefit of using similarities between presentation layer and data source layer to create symmetric components made of a core surrounded by interfaces, but with the drawback of hiding the inherent asymmetry between a service provider and a service consumer that would better be represented as layers.<ref>{{Cite book|url=https://www.worldcat.org/oclc/50292267|title=Patterns of enterprise application architecture|last=Fowler, Martin,|first=|date=2003|publisher=Addison-Wesley|year=|isbn=0-321-12742-0|___location=Boston|pages=21|oclc=50292267}}</ref>

== Evolution ==

According to some authors, the hexagonal architecture is at the origin of the [[Microservices|microservicemicroservices]]<nowiki/>s architecture.<ref>{{Cite book|url=https://www.worldcat.org/oclc/999610958|title=Spring 5.0 microservices : build scalable microservices with Reactive Streams, Spring Boot, Docker, and Mesos|last=Rajesh R. V,|first=.|publisher=Packt Publishing|year=2017|isbn=978-1-78712-051-8|edition= Second edition|___location=Birmingham, UK|pages=13-1413–14|oclc=999610958}}</ref>

== Variants ==

The onion architecture proposed by JeffryJeffrey Palermo in 2008 is similar to the hexagonal architecture: it also externalizes the infrastructure with proper interfaces to ensure loose coupling between the application and the database.<ref>{{Cite web|url=https://jeffreypalermo.com/2008/07/the-onion-architecture-part-1/|title=The Onion Architecture : part 1|last=Jeffrey|first=Palermo|date=2008-07-29|website=Programming with Palermo|language=en-US|access-date=2019-08-12}}</ref> It decomposes further the application core into several concentric rings using [[inversion of control]].<ref>{{Cite book|url=https://www.worldcat.org/oclc/937787252|title=Learning NHibernate 4 : explore the full potential of NHibernate to build robust data access code|last=Chatekar, Suhas,|first=|publisher=Packt Publishing|year=2015|isbn=978-1-78439-206-2|___location=Birmingham, UK|pages=249-250249–250|oclc=937787252}}</ref>

The clean architecture proposed by [[Robert C. Martin]] in 2012 combines the principles of the hexagonal architecture, the onion architecture and several other variants;. It provides additional levels of detail of the component, which are presented as concentric rings. It isolates adapters and interfaces (user interface, databases, external systems, devices) in the outer rings of the architecture and leaves the inner rings for [[use case]]s and [[Entity class|entities]].<ref>{{Cite web|url=https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html|title=The Clean architecture {{!}} Clean Coder Blog|last=Martin|first=Robert, C.|date=2012-08-12|website=blog.cleancoder.com|archive-url=|archive-date=|dead-url=|access-date=2019-08-12}}</ref>^,.<ref>{{Cite book|url=https://www.worldcat.org/oclc/1004983973|title=Clean architecture : a craftsman's guide to software structure and design|last=Martin, Robert C.,|publisher=Prentice Hall|year=2017|isbn=978-0-13-449416-6|___location=London, England|oclc=1004983973}}</ref> The clean architecture uses the principle of [[Dependency inversion principle|dependency inversion]] with the strict rule that dependencies shall only exist between an outer ring to an inner ring and never the contrary.

== See also ==

Line 33 ⟶ 39:

* [[Layer (object-oriented design)]]

* [[Composite structure diagram]]

* [[Object-oriented analysis and design|Object oriented Analysisanalysis and design]]

== References ==

{{Reflist}}<br />

[[Category:Software design]]