Hexagonal Architecture (Alistair Cockburn)

Learn from it’s creator the rules and structure of the “Hexagonal”, more correctly called the Ports & Adapters architecture. In this lecture, Dr. Cockburn will describe why he created it, its benefits and also its costs, the UML description, and also some sample code. As an extra challenge, he will invite you to write your first Ports & Adapters application in your favorite language /during/ the talk!
Outline of the lecture:
Challenge to write a small application during the lecture
Short form what the code looks like
Costs, benefits, history: why was it needed
Viewing your application as a component
Development sequence
Examples in Ruby & Java with needed terminology
How to set up the folders
The various ways to set up the architecture
Why is it called /Hexagonal/?
Summary, checking in with people who accepted the challenge
ABOUT ALISTAIR
Dr. Alistair Cockburn (pronounced CO-BURN) was named as one of the “42 Greatest Software Professionals of All Times" in 2020, as a world expert on methodologies, project management, software architecture, use cases and agile development. He co-authored both the Agile Manifesto in 1002. Since 2015 he has been working on expanding agile to cover every kind of initiative, including social impact projects, governments, and families.
Dr. Cockburn developed the “Hexagonal” or Ports & Architecture over several decades out of frustration seeing projects suffer from not being able to swap drivers and databases easily. For his latest work, see alistaircockbu....
LinkedIn: / alistaircockburn
Twitter: x.com/totheral...
GitHub: github.com/tot...
Personal site: alistaircockbu...
TECH EXCELLENCE
Subscribe to our TH-cam channel / @techexcellence
Join our Meetup Group www.meetup.com...
Follow us on LinkedIn / techexcellenceio
Follow us on Twitter / techexcellence_
Join our Discord Community / discord
#hexagonalarchitecture #softwareengineering #techexcellence

[@theachannel2157]

What a co-incidence - I got interested in Hexagonal Architecture today and this was streamed yesterday

[@chrishoward7976]

This is a nice intro. Ports and adapters is such an awesome pattern, but you see it again and again that the terminology confuses people (it was evident in the live chat, too). And while I understand the hand-waving away of specific concerns, given that AC will have been using ports and adapters for the best part of a decade now, some real world practical “recipes” and model examples for different stacks could really help.

[@TechExcellence]

Yes, many developers have been requesting guidance regarding specific concerns about implementing Hexagonal Architecture.
Alongside the TDD in Legacy Code series, there are also plans for Hexagonal Architecture in Legacy Code series - to give specific guidance about introducing Hexagonal Architecture.
journal.optivem.com/p/tdd-in-legacy-code-transformation

[@BlindVirtuoso]

Thanks Alistair. Nice one, appreciate it. Though you drew an ideal world picture and problems emerge when abstractions start to leak or when a port abstraction boundary is wrong

[@MarianVarga-wr1rl]

I asked about optimistic locking and transactions and @Rob van der Linden Vooren asked a similar thing about propagating context from/to adapters. Unfortunately, the answer is "I don't care". This sounds like an "ivory tower" architecture to me...

[@kfsama]

Hi! I'm not really used to this specific approach, but I do try to isolate interfaces and their responsibilities in my work, so what Alistair says landed nicely in my mind.
To try to figure out some working design of the interfaces, I'd start by asking questions like this to myself:
For passing of the context: is it an important part that should be accessed and used in the app itself? I'll make it a part of each interface then (both driving and driven).
Or is it an implementation detail? Then I'd try to delegate this to the supporting libraries, to make it a sideband context and then work on supporting it on all types of the adapters (which can be a tedious task and it would be an easy thing to lose). If there is no way to do that in the language/ecosystem, then only option A is left.
For supporting a transaction or distributed transaction:
Is it an important part of the app itself? I'd expose the transaction control on the driven interfaces and make some kind of transaction manager your required dependency. Then wire it up in the app configuration, so it would control all the driven interfaces that need that management.
Or is it just an implementation detail? Then I'd make the transaction control a part of your adapter that would expose only "Save" method on the complex object to the app and do all the work without exposing the complexity of the actual storage.
For optimistic locking:
Is it important to the application? I'd expose the "Update" method with both expected and desired state of the object as the parameters and make it properly return the updated state with failure status or success status as a result
Is it an implementation detail for which I can figure out the automatic resolver of the conflicts? Then I'd expose the "Update" method with the set of desired changes to the object state
What do you think, should these approaches and this way of thinking work?