Hexagonal architecture (software): Difference between revisions

Content deleted Content added
m fix capitalization
Tags: Visual edit Mobile edit Mobile web edit Advanced mobile edit
m clean up spacing around commas and other punctuation fixes, replaced: ; → ;
Line 14:
 
The granularity of the ports and their number is not constrained:
* 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.
Line 22:
== Criticism ==
 
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|hexagonalhexagon]]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 [[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|title=Patterns of enterprise application architecture|last=Fowler, Martin|date=2003|publisher=Addison-Wesley|isbn=0-321-12742-0|pages=21|oclc=50292267}}</ref>
Line 43:
== References ==
{{Reflist}}
 
[[Category:Software design]]
[[Category:Architectural pattern (computer science)]]