"Program to an interface, not an implementation" is related, but I see a distinction. The interface/implementation principle is one of the two design principles of Design Patterns. It is realized in several design patterns, such as Strategy, Template Method, Façade and to some degree Adapter. I view Hexagonal Architecture/Ports&Adapters as pattern of these patterns that pulls them together into a cohesive design. I have blogged about this, and I have my own HexArch/P&A video presentation online, but I am reluctant to post any links here. Every time I post a comment with links, it get's removed by RUclips. I suspect it's trying to avoid self promotion.
It's the separation of outside and inside and the responsibilities that should be separated. You could implement interfaces and still have confused responsibilities.
You introduced the adapter just in time 😉. I like your style here, it's actually an emergent (description of a) design. My only critique would be that outside circle: Alistair always emphasizes that P P&A has no layering (although I can definitely understand why people view it that way). An example that shows this is when your test suite is calling the port. The test suite is an actor that needs no adapter, and so your outside circle would be empty
Even for someone familiar with the architecture this was very engaging and enjoyable to watch. Waiting for more!
Nice one. Appreciate it. Thanks, Vaughn
Just the best explanation on hexagonal I've seen so far.
Would add that this also benefits testability.
My guess is that Vaughn will add these in coming episodes.
Thanks Vaughn, but i really wonder, how is something new compared to the classic: “depend on the interface, not the implementation” ?
"Program to an interface, not an implementation" is related, but I see a distinction.
The interface/implementation principle is one of the two design principles of Design Patterns.
It is realized in several design patterns, such as Strategy, Template Method, Façade and to some degree Adapter.
I view Hexagonal Architecture/Ports&Adapters as pattern of these patterns that pulls them together into a cohesive design.
I have blogged about this, and I have my own HexArch/P&A video presentation online, but I am reluctant to post any links here. Every time I post a comment with links, it get's removed by RUclips. I suspect it's trying to avoid self promotion.
It's the separation of outside and inside and the responsibilities that should be separated. You could implement interfaces and still have confused responsibilities.
Was already yelling at my TV thinking somebody would explain P&A wrong AGAIN when you said "the port receives an HTTP request" 😂
Hope you didn't stop there 😊
You introduced the adapter just in time 😉. I like your style here, it's actually an emergent (description of a) design. My only critique would be that outside circle: Alistair always emphasizes that P
P&A has no layering (although I can definitely understand why people view it that way). An example that shows this is when your test suite is calling the port. The test suite is an actor that needs no adapter, and so your outside circle would be empty
Nice!
Nice!