We all know this situation: the older and larger an application gets, the more complex and expensive it becomes to expand and maintain it. The widespread layered architecture is inadequate as a solution approach: direct and indirect dependencies of all layers on the database and other infrastructure components often lead to a blurring of the layer boundaries and an interweaving of technical and functional code.
Hexagonal architecture places the business logic at the center, and technical details are isolated as adapters behind interfaces (ports). Business and technical code can thus be developed and tested independently of each other.
Based on the objectives of a software architecture and a critical look at the layered architecture, we take a detailed look at the hexagonal architecture. You will learn how the dependency rule ensures that there are no dependencies between functional and technical code and how the application core can still access the infrastructure. Does the hexagonal architecture fulfill the goals of a software architecture? What challenges does it bring with it? How does it differ from onion and clean architecture, and what synergies arise in interaction with microservices and domain-driven design?
Equipped with new knowledge, you can increase the quality and lifespan of your software projects and react more quickly to new requirements in the future.
svenwoltmann
ymd65536
syossan27
1mash0
kubode
nrslib
josepaumard
kateinoigakukun
nobu74658
cocoeyes02
ydah
dmnlk
watabee
sergeychernyshev
addyosmani
eileencodes
bkeepers
dougneiner
lara
chriscoyier
tammyeverts
3n
keavy
jnunemaker
