Hexagonal Architecture Episode 2 Ports amp Adapters

>> YOUR LINK HERE: ___ http://youtube.com/watch?v=bw7So5GMkyg

Hexagonal Architecture does NOT prescribe layers. It ONLY prescribes dependency inversion. • What is the essence of Hexagonal Architecture? • INVERSION OF CONTROL • The essence behind Hexagonal Architecture is the Inversion of Control. To illustrate the difference: • In Traditional Layered Architecture, the Presentation Layer calls the Business Layer, and the Business Layer calls the Database Layer. • Translating this to Hexagonal Architecture, the Presentation Layer calls the user-side interface exposed by the Business Layer (and the Business Layer implements the user-side interface); furthermore, the Business Layer also declares (and calls) the data-side interface (which represents abstract access to persistence); lastly, the Database Layer implements the data-side interface (e.g, ORM, SQL). This is just an informal overview, so that you can understand it. But, more formally (since we will not use the word layers ) - on the user-side, the Driver Adapters call the Driver Ports, and on the server-side, the Driven Adapters implement the Driven Ports. The Application exposes both Driver Ports Driven Ports. • From this, we can see that the essence of Hexagonal Architecture is that it breaks direct dependencies. So, the Presentation does NOT depend on the Business implementation. The Business implementation does NOT depend on the Database implementation. • For a more formal overview, see Alistair Cockburn's article https://lnkd.in/d4pBs_br • LAYERING IS NOT PRESCRIBED • Hexagonal Architecture does NOT specify what kind of layers you'll have inside the Hexagon itself. • This was well summarized by Juan Manuel Garrido de Paz (https://lnkd.in/eWCm_J_H): • Ports Adapters pattern says nothing about the structure of the inside of the hexagon. You can have layers… you can have components by feature… you can have spaghetti code… you can have a Big Ball of Mud… you can apply DDD tactical patterns… you can have a single CRUD… it’s up to you. • So we can structure the Hexagon in any way we like, which includes: • Big Ball of Mud • Transaction Script • Domain Driven Design • Onion Architecture • Clean Architecture • I show all the above in the YouTube video. • HEXAGONAL ARCHITECTURE + CLEAN ARCHITECTURE • We've said above that the internals of the Hexagon can be implemented in ANY way, it is not prescribed; there is no prescription whether we'll have layers or vertical slicing or anything else. • ONE way we could structure the Application implementation is using Clean Architecture layers - Use Cases Domain; ANOTHER way to structure it is using Transaction Script. • Key distinction: • Hexagonal Architecture defines the outermost specifications • Clean Architecture is superimposed on top, as just one of many approaches • LINKS: • Miro Board: https://miro.com/app/board/uXjVMcx1pU... • Article: https://journal.optivem.com/p/hexagon... • FOLLOW: • Newsletter: https://journal.optivem.com • LinkedIn: / valentinajemuovic • Twitter: https://x.com/valentinajemuov • GitHub: https://github.com/valentinajemuovic • Instagram: / valentinajemuovic • YouTube: / @valentinajemuovic • Discord: / discord • #hexagonalarchitecture #unittesting #tdd #softwareengineering #optivem

#############################

New on site